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ABSTRACT 

This  thesis  provides  a  description  of  a  collection  of  "tools"  which  may  be  used 
by  acquisition  program  managers.  The  Modular  Command  and  Control  Evaluation 
Structure  (MCES)  provides  the  framework  for  management  of  the  process.  The 
Marine  Corps  Technical  Interface  Concepts  (TIC)  and  interoperability  database  (IDB) 
are  discussed  as  standards  for  filling  four  of  the  seven  MCES  modules.  Finally,  generic 
measures  of  communications  system  performance  are  described  and  used  in 
conjunction  with  System  Effectiveness  Analysis  (SEA)  to  define  the  analytical  process 
of  measuring  effectiveness. 
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I.  INTRODUCTION 

A.       BACKGROUND 

Acquisition  of  major  weapons  systems  has  become  a  progressively  more 
complicated  process.  This  is  due,  in  part,  to  the  complexity  of  modern  warfare. 
Integrated  (interoperable)  command  and  control  (C")  systems  are  required  to 
effectively  harness  and  employ  the  destructive  nature  of  military'  forces.  Integration 
demands  measures  to  overcome  technical  intricacies  and  efforts  to  master  the  political 
and  cultural  pressures  highlighted  in  the  following  quote  [Ref.  1:  p.  ii]. 


GETTING  INTERSERVICE  AGREEMENT  IS  THE  MOST  DIFFICULT 
PHASE:  Service  diflerences  in  doctrines,  operations,  logistics,  and  procedures 
tend  to  diversify  svstem  designs.  When  joint  acquisitions  are  ordered  bv  the 
Secretary  of  Defense  or  the  Congress,  the  biggest  hurdle  is  getting  the  services  to 
agree  oh  joint  requirements.  Each  service  "Believes  that  its  concept  of  a  new 
aircraft,  missile,  or  vehicle  will  be  best  for  the  mission  and  will  oppose 
compromise  of  its  design  or  performance  goals.  Agreement  is  still  more  elusive 
when  one  or  another  svstem  is  already  well  into  development  with  a  "hardened'' 
design,  decisions  firmed,  costs  sunk,  and  a  dedicated  constituency  in  place.  This 
is  when  many  program  mergers  are  ordered. 


The  Department  of  Defense  has  outlined  procedures  directed  at  resolving  integration 
(interoperability)  issues.  At  the  heart  of  this  enterprise  is  a  requirement  to  outline  a 
joint  Command,  Control  and  Communications  (C  )  architecture  and  to  build  a  joint 
interoperability  database  [Ref.  2:  p.  4-5].  The  multifarious  nature  of  this  endeavor 
makes  it  necessary  to  collect  tools  to  describe,  in  structured  terms,  the  process  of 
command  and  the  communications  necessary  to  control  diverse  elements. 

B.       SCOPE 

This  thesis  will  focus  on  four  tools  that  can  be  used  by  acquisition  managers  to 
consolidate  and  refine  the  measures  and  specifications  necessary  to  affect  a  systematic 
approach  to  procurement.  Specifically,  these  devices  can  assist  supervisors  in  refining 
mission  needs  and  stipulating  the  requirements  necessary  to  meet  these  demands.  The 
Modular  Command  and  Control  Evaluation  Structure  (MCES)  will  provide  the 
framework  for  evaluating  C  architectures.  Generic  system  attributes  need  to  be 
defined  and  assigned  numeric  values,  where  possible  and  practical,  to  be  analyzed. 
This  thesis  will  define,  in  the  author's  words,  essential  communications  considerations 
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used  by  Marine  Corps  communications  managers.  Marine  Corps  Technical  Interface 
Concepts  (TIC)  are  applied  to  describe  the  boundaries  and  process  definitions, 
integrate  these  descriptions,  and  then  provide  data  for  specified  measures.  Finally, 
System  Effectiveness  Analysis  (SEA)  outlines  a  quantitative  approach  to  aggregate  and 
evaluate  recommended  measures. 

C.       THESIS  OUTLINE 

This  thesis  is  organized  into  eight  chapters.  Chapter  II  describes  the  framework 
of  VICES,  in  acquisition  related  terms.  Chapter  III  defines  communications  attributes. 
While  not  an  all-encompassing  list,  it  provides  generic  considerations  to  be  used  to 
specify  Measures  of  Performance  or  Effectiveness.  Chapter  IV  outlines  the  Marine 
Corps  Technical  Interface  Concepts  followed  by  an  explanation  of  System 
Effectiveness  Analysis  (Chapter  V).  Chapter  VI  then  applies  the  previously  described 
tools  to  a  CJ  system.  Chapter  VII  summarizes  the  results  and  recommends  areas  for 
further  research.  Appendix  A  provides  a  dictionary  of  acronyms  and  terms  used  to 
describe  this  process.  The  sources  for  these  definitions  include  JCS  Publication  1, 
"DoD  Dictionary  of  Military  and  Associated  Terms,"  January  1986,  and  the  references 
cited  throughout  the  text.  This  thesis  assumes  a  basic  knowledge  of  communications 
engineering  principles  and  of  the  acquisition  process.  Appendix  B  provides  an 
overview  of  the  acquisitions  process.  Inasmuch  as  regulations  are  constantly  changing, 
Appendix  B  is  somewhat  dated;  however,  the  principles  and  structure  remain  essentially 
unchanged. 
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II.  MODULAR  COMMAND  AND  CONTROL  EVALUATION 
STRUCTURE  (MCES)  METHODOLOGY 

A.  INTRODUCTION 

The  Modular  Command  and  Control  Evaluation  Structure  (MCES)  is  a 
framework  for  systems  planners  and  evaluators  to  assess  C  architectures.  By 
extension,  it  is  a  useful  basis  for  analyzing  the  communications  processes  necessary  to 
support  command  and  facilitate  control.  Its  functional  applications  may  extend 
beyond  the  bounds  of  CJ  studies.  This  thesis  will  concentrate  on  defining  its  utility  as 
an  acquisitions  guide  to  evaluate,  inter  alia,  communications  interoperability. 

B.  BACKGROUND 

The  development  of  MCES  was  initially  triggered  by  a  challenge  to  Air  Force 
planners  to  determine  the  force  effectiveness  of  C  systems.  This  implied  a  search  for  a 
means  of  analyzing  these  systems  throughout  their  life-cycle.  Expert  knowledge  of  the 
analytic  community  was  focused  through  a  conference  chaired  by  Dr.  Ricki  Sweet  and 
LtCol  Thomas  Fagan  III.  USAF.  Five  working  groups  were  formed  to  address: 
Definitions,  Conceptual  Models,  the  Identification  of  Measures  of  Effectiveness 
(MOEs).  Evaluation  Techniques  and  Approaches  and  an  overall  appraisal  of  the 
current  status  and  future  course  of  MOE  analysis. 

Based  on  an  expressed  interest  and  need  for  further  attention  to  C^  systems' 
contribution  to  force  effectiveness,  an  effectiveness  "strawman"  was  developed  by  Drs. 
Mort  Metersky,  Michael  G.  Sovereign,  and  Ricki  Sweet  to  provide  a  framework  for 
subsequent  deliberations  at  the  MORS  (Military  Operations  Research  Society) 
sponsored  workshop.  An  integrated  document  describing  VICES  was  published  in  June 
1986  [Ref.  3:  pp.  19-21].  MCES  has  been  tested  and  refined  through  service 
community  input  [Ref.  4]  and  through  the  voluntary  contribution  of  government, 
military  and  civilian  agencies,  and  companies  [Ref.  3:  p.  24]. 

This  chapter  provides  an  explanation  of  MCES  presented,  where  appropriate, 
with  reference  to  DoD  acquisition  requirements.  It  is  a  restatement,  in  the  author's 
words,  of  the  methodology  described  by  Dr.  Sweet  [Ref.  3:  pp.  9-18]. 
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Figure  2.1     The  Modular  Command  and  Control  Evaluation  Structure. 

C.       METHODOLOGY 

The  MCES  (Figure  2.1)  consists  of  two  components:    (1)  managerial  and  (2) 
analytical  systems.    The  former  guides  the  user  through  specification  while  the  latter 
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outlines  analysis  processes  (both  objective  and  subjective).  The  MCES  is  intended  to 
guide  problem  specification  and  analysis  in  order  to  provide  a  manager  with  concise 
conclusions  thereby  enhancing  decision  making.  This  direction  is  accomplished 
through  use  of  seven  modules  using  pragmatic,  established  techniques. 

1.  Module  1:  Problem  Formulation 

Module  1  describes  the  decision  maker's  objectives.  These  objectives  should 
fill  a  mission  need  and  demonstrate  a  level  of  performance  and  reliability  that  justify 
the  allocation  of  the  Nation's  limited  resources  for  the  system's  ownership  and  or 
acquisition  [Ref.  5:  p.  4].  Implementation  of  this  module  results  in  a  more  precise 
statement  of  the  problem  to  be  addressed.  Problem  formulation  should  consider 
elements  of  not  only  mission  assignment  but  also  the  intelligence  or  threat  assessment 
and  scenario(s)  underlying  the  analysis. 

2.  Module  2:  C~  System  Bounding 

The  problem  statement  developed  in  Module  1  is  then  used  to  bound  the  C 
system  of  interest.  This  module  has  been  perhaps  one  of  the  most  overlooked  elements 
in  preparation  of  acquisition  strategies  and  Justification  for  Major  System  New  Starts 
(JMSNS).  Bounding  the  project  allows  managers  and  engineers  to  focus  their  efforts 
rather  than  attempt  description  of  a  panacea  for  all  existing  deficiencies.  Module  2 
specifies  the  first  two  of  the  three  dimensions  which  define  a  C    system,  namely: 

•  physical  entities  (equipment,  software,  people  and  facilities); 

•  structure  (organization,  concepts  of  operation  and  information  flow  patterns); 
and, 

•  process  (the  functionality  or  "what  the  system  is  doing"). 

Bounding  in  this  module  occurs  when  the  project  team  defines  who  or  what  entities 
have  a  requirement  to  interact  (process  -  the  final  C  dimension  developed  further  in 
the  next  module)  in  what  manner  or  along  what  lines  (structure). 

3.  Module  3:  C~  Process  Definition 

Understanding  the  system  bounds  allows  a  focused  description  of  Command 
and  Control  processes  (Module  3).  Other  generic  models  such  as  Boyd's  O-O-D-A  and 
Lawson's  control  loop  are  applied  to  force  attention  on: 

•  the  environmental  "initiator"  of  the  C^  process; 

the  internal  processes  that  characterize  what  the  svstem  is  doing  (ex.  sense, 
assess,  generate,  select,  plan,  and  direct)  (see  Figure  2.2);  and; or, 

the  inputs  and  desired  outputs  from  the  internal  process. 


• 
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Figure  2.2    Generic  Command  and  Control  Process. 

4.  Module  4:  Integration  of  System  Elements  and  Functions 

The  fourth  module  verbally  or  graphically  depicts  the  three  dimensional 
system.  It  maps  entities  with  their  required  processes,  forming  the  structure  necessary 
to  answer  the  mission  objective  of  Module  1.  Techniques  such  as  Data  Flow  Diagrams 
(DFDs)  are  frequently  used  to  show  the  information  (low  through  the  model. 
Hierarchical  relationships  are  drawn  as  data  progresses  through  the  system  to  a 
decision  maker  or  into  master  databases  for  further  or  future  processing. 

5.  Module  5:  Specification  of  Measures  (Criteria) 

The  definitive  processes  of  the  preceding  modules  lead  logically  to  the 
specification  of  measures  necessary  to  address  the  problem  of  interest.  These  measures 
are  classified  as  to  their  level  of  measurement. 
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a.  Measures  of  Performance  (MOPs) 

Measures  of  Performance  are  specified  inside  the  boundary  of  the  O 
system  [Ref.  4:  p.  17],  that  is.  they  measure  performance  of  the  system  processes.  A  set 
of  generic  Communications  MOPs  will  be  presented  in  Chapter  III.  An  example  of  a 
communications  performance  measure  would  be  a  specific  bit  error  rate  (BER) 
requirement  for  a  data  transmission  system. 

b.  Measures  of  Effectiveness  (MOEs) 

Measures  of  Effectiveness  (MOEs)  are  specified  outside  the  boundary  of 
the  communications  system  [Ref.  4:  p.  17].  MOEs  are  C  process  measures  placed  on 
the  system  being  evaluated  in  the  context  of  the  system's  effect  on  the  larger  (Force) 
process.  They  describe  a  force  action  or  lack  thereof  impacted  or  directed  by  the 
system.  As  an  example,  in  order  to  ENGAGE  an  enemy  (Force  level)  you  first  have  to 
FIND  or  LOCATE  (system  level)  him. 

c.  Measures  of  Force  Effectiveness  (MOFEs) 

Measures  of  Force  Effectiveness  (MOFEs),  then,  describe  the  force  effect 
on  its  environment.  These  combine  all  of  the  system's  performance  and  effectiveness 
measures  and  could  describe  such  things  as  battle  outcome  or  target  destruction. 
Figure  2.3  portrays  the  aforementioned  relationships. 

The  specified  measures  are  subjected  to  further  scrutiny  by  comparing  them 
to  a  set  of  criteria  (Table  1)  reducing  the  number  to  a  more  manageable  set.  The  final 
list  is  taken  to  be  critical  or  the  minimum  necessary  to  measure  the  problem  at  hand. 

6.  Module  6:  Data  Generation 

Module  6  addresses  the  requirement  to  generate  data  relative  to  the  Measures 
specified  in  Module  5.  Data  can  be  generated  through  any  number  of  means  (i.e., 
exercises,  experiments,  simulations,  or  subjective  judgement).  In  the  acquisition 
process,  values  are  generated  for  specified  measures  relative  to  the  force  and 
environment  (MOE  MOFEs)  and  then  to  system  entities  (MOPs).  This  would  imply  a 
top-down  design  approach.  It  also  implies  an  iterative  process  wherein  specification 
dependencies  are  highlighted,  analyzed  and  resolved.  Chapters  IV  and  V  will  describe  a 
means  of  acquiring  data  to  describe  the  generic  communications  MOPs  outlined  in 
Chapter  III. 

7.  Module  7:  Aggregation  of  Measures 

The  final  module  addresses  aggregation  or  analysis  of  the  previously  defined 
system.    As  support  for  a  JMSNS,  analysis  may  determine  the  essential  features  of  a 
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new  system's  effect  on  the  force  compared  with  programs  already  in  existence  (DoD 
Milestone  0).  Following  a  decision  to  acquire  (DoD  Milestone  1),  investigation  is 
conducted  into  alternative  means  in  order  to  refine  requests  for  proposals  (RFPs)  and 
generate  a  specific  statement  of  work  (SOW).  Finally,  the  system  measures  are 
compared  with  proposals  and  products  through  the  full  scale  development  phase  and 
used  to  determine  contractor  qualification  for  contract. 

Existing  systems  are  evaluated  as  changes  to  mission  statements  and  objectives 
are  directed  to  demonstrate  or  validate  their  utility  in  the  force  as  a  whole. 

D.       DECISION  MAKER 

The  products  provided  by  the  MCES  modules  are  presented  to  a  decision  maker. 
Three  general  courses  of  action  are  then  available.  The  results  may  be  implemented 
based  on  the  analysis.  Alternatively,  a  need  for  further  study,  refining  any  or  all  of  the 
Modules,  may  be  directed.  Finally,  a  decisionmaker  may  terminate  the  process. 
VICES  does  not  define  a  specific  decision  process.  This  is  left  to  the  manager  to 
describe.  The  process  may  be  entirely  subjective  based  on  the  evaluator's  personal 
assessment  of  the  data  generated.  It  may  be  very  objective,  based  solely  on  numbers 
generated  combined  with  weighted  measures.  Or  it  could  encompass  any  combination 
of  these  processes.  As  a  generic  tool,  MCES  specifies  only  the  logical  framework  or 
process  of  the  evaluation.  It  remains  a  function  of  leadership  to  define  the  decision 
process. 


CONTEXT 

(SCENARIO)  , 


'design    parameters 


ENVIRONMENT 


CONTEXT 
(SCENARIO) 


MOP   - 

Measure  of   Performance 

MOE    - 

Measure   of   Effectiveness 

MOFE 

-   Measure   of   Force   Effectiveness 

MOPE 

-   Measure   of   Policy   Effectiveness 

MEO    - 

Message    Exchange   Occurence 

(See  Chapter  IV) 

NCA  • 

National  Command  Authority 

Figure  2.3     Measures  Specification  -  The  "Onion  Skin' 
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TABLE  1 

CRITERIA 

CHARACTERISTICS 

DEFINITIONS 

Mission  Oriented 

Relates  to  force/system  mission 

Discriminatory 

Identifies  real  difference  between 
alternatives 

Measurable 

Can  be  computed  or  estimated 

Quantitative 

Can  be  assigned  numbers  or  ranked 

Realistic 

Relates  realistically  to  the  C2  system 
and  associated  uncertainties 

Objective 

Can  be  defined  or  derived,  independent 
of  subjective  opinion.  (It  is  recognized 
that  some  measures  cannot  be 
objectively  defined). 

Appropriate 

Relates  to  acceptable  standards  and 
analysis  objectives 

Sensitive 

Reflects  changes  in  system  variables 

Inclusive 

Reflects  those  standards  required 
by  the  analysis  objectives 

Independent 

Is  mutually  exclusive  with  respect 
to  other  measures 

Simple 

Is  easily  understood  by  the  user 
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III.  MEASURES 

A.  INTRODUCTION 

The  MCES.  described  in  Chapter  II,  directed  specification  of  measures  as  the 
requirement  for  Module  5  of  the  Structure.  This  chapter  will  describe  the  efforts  of 
JTC  A  in  their  research  on  specifying  measures  [Ref.  6]  and  then  outline  generic 
communication  system  measures,  recommended  by  this  author,  to  be  considered  as  a 
guide  in  acquisition  planning.  The  Technical  Report  referenced  in  the  introduction  and 
its  accompanying  appendix  [Ref.  7]  present  the  preliminary  JTC  A  results  on 
assessment  and  evaluation  techniques  for  joint  tactical  command,  control  and 
communications  systems,  networks,  links  and  facilities.  The  JTC  A  work  has 
attempted  definition  of  MOE's  for  five  major  C"  elements  (see  Table  2).  In  keeping 
with  the  thesis  scope,  the  controlling  factors  outlined  will  refer  to  the  communications 
element  of  the  C    architecture. 

B.  BACKGROUND 

Analysts  define  and  use  MOEs  in  the  development  of  system  and  sub-system 
architectures.  Commencing  with  work  conducted  by  the  Joint  Tactical 
Communications  Office  (TRI-TAC)  in  the  1970-80  time  period  in  which  seventeen 
measures  were  published,  to  date  about  two  hundred  MOEs  have  been  identified  and 
defined  by  JTCJA  [Ref.  6:  p.  4].  Some  of  these  are  hardware  oriented  and  therefore 
technical  in  scope  such  as  "ECCM  LPI",  "Antenna  Gain",  and  "Transmission  Power." 
Others  are  non-technical  requirements  relating  to  such  functions  as  "Monitoring", 
"Capability  to  Select  Options,  Employ  Forces,  and  Execute  Operations"  and 
"Responsiveness  to  Warning  and  Threat  Assessments."  Certain  measures  address  total 
system  orientation  such  as  "Maintainability",  "Survivability",  and  "Mobility."  JTC  A 
emphasizes  that  "...these  MOEs  are  structured  for  preliminary  design  comparison."  In 
the  MCES  framework,  they  are  also  useful  when  applied  and  evaluated  in  an  iterative 
fashion  as  tools  to  define  the  system  or  sub-system  bounds.  In  other  words 
specification  of  the  measures  themselves  may  help  refine  initial  bounding  when 
performance  or  effectiveness  standards  (MOPs  MOEs)  fail  to  meet  or  answer  problem 
objectives.  This  occurs  as  the  decision  maker  is  presented  with  architectural 
alternatives  which  address  a  stated  mission  need  (determined  in  Module  1). 
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C.  MOE  ORGANIZATION  AND  FORMAT 

The  JTCJA  listing  of  MOEs  is  organized  into  five  groups  as  shown  in  Table  2 
These  correspond  to  the  five  major  C  elements  mentioned  in  OJCS  SM-7-82 
[Ref.  6:  p.  5].  They  are  divided  further  into  sub-elements,  also  illustrated  in  Table  2. 
Communications  is  visualized  as  the  bonding  agent  of  C  systems  and  is  categorized  in 
terms  of  "transmission"  and  "connectivity/distribution."  Keeping  with  the  scope  of  this 
work,  this  author  will  describe  the  Communications  category  and  specific  generic 
measures  to  be  considered  when  describing  or  defining  a  system.  This  is  contrary  to 
the  global  JTCJA  approach  wherein  measures  are  specified  by  communications  media 
type. 

Reference  7  uses  the  format  presented  in  Table  3  to  present  specific  measures. 
Inasmuch  as  this  represents  a  goal  which  JTC°A  has  yet  to  realize,  the  title  and 
definition  of  each  measure  will  be  used  in  this  thesis.  Comments  regarding  evaluation 
will  be  presented  in  a  discussion  section.  Sources  and  data  requirements  will  be 
omitted  for  the  generic  measures.  The  "MOP  or  MOD  Title"  line  refers  to  the 
Measures  of  Performance  (MOP)  previously  discussed  and  Measures  of  Design  (MOD) 
representing  field  operational  characteristics  (ex.,  "Transportability"  and 
"Maintainability").  The  reference  admits  no  great  significance  in  the  distinction 
[Ref.  6:  p.  6].  In  order  to  prevent  confusion  and  follow  the  MCES  outline,  only 
"MOPs"  will  be  listed  in  the  title  lines  for  this  work. 

D.  GENERIC  MEASURES 

1.  Introduction 

This  section  presents  generic  measures  of  performance  to  be  applied  to 
communications  systems  analysis  in  the  MCES  framework.  The  measures  listed  are  in 
no  particular  order  of  importance.  While  perhaps  lacking  in  depth  of  description  and 
breadth  of  attribute  (measure)  coverage,  it  should  provide  the  reader  a  skeleton  on 
which  to  build  a  more  comprehensive  listing.  It  is  understood  that  many  of  these 
measures  are  interrelated.  Parameters  or  characteristics  of  one  may  impact  or  affect 
another.  Some  of  these  relations  are  highlighted.  Others  may  have  been  omitted.  It 
remains  a  requirement  for  the  analysis  team  using  these  measures  to  describe 
interdependencies  as  complementary  or  disparate  and  develop  the  decision  tools  to 
compromise  or  obviate  differences.  JTC  A  also  emphasized  that  their  measures  are 
proposed  for  communications  systems  only.    This  also  applies  herein.    The  measures 
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TABLE  2 

ORGANIZATION  OF  JOINT  TACTICAL  C3  MOC  CATEGORIES 

1. 

Commai 
A. 
B. 

id  Facilities 

Main  Command  Centers 
Alternate  Command  Centers 

2. 

Commu 
A. 
B. 
C. 
D. 
E. 
F. 
G. 

nicatlons 

Tactical  HF  Systems 
Line  of  Sight  Systems 
Tropo 
Switching 

Wire/cable/fiber  optics 
Satellite 
Combined  System  Networks 

3. 

Warninc 

(Surveillance) 

A. 
B. 
C. 
D. 

E. 

Ground 
Surface 
Sub-surface 
Space  Based 
Tethered  Balloons 

4. 

Comma 

nd  and  Control  Procedures 

A. 
B. 
C. 
D. 

Procedures 
Reports 
Frame  Formats 
Modularity  Techniques 

5. 

Comma 

nd  and  Control  Data  Collection  and  Processing 

A. 
B 
C 

Netted  Systems 
Centralized  Data  Bases 
Point-to-point  Systems 

discussed  stem  from  system  attributes  defined  for  Marine  communications  managers. 
It  is  felt  that  attributes  of  an  efficient  effective  communications  system  should  relate  to 
measures  used  in  evaluating  proposed  and  existing  systems. 
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TABLE  3 

FORMAT  FOR  EACH  MOE 

MOP  or  MOD  TITLE: 

DEFINITION:  or  description  of  what  the  title  measures 

METHODOLOGY:  either  qualitative  or  quantitative  for  preparing 
the  measure,  Including  Important  parameters,  factors, 
models  and  considerations 

SOURCES:  that  are  useful  for  further  research 

DATA  REQUIREMENTS:  for  using  the  algorithms  and  models 

2.  Reliability 

a.  Definition 

Measures  (the)  probability  that  an  item  will  perform  its  intended  function 
for  a  specified  interval  under  stated  conditions  [Ref.  7:  p.  A- 14]. 

b.  Discussion 

Reliability  is  usually  expressed  in  terms  of  Mean  Time  Between  Failure 
(MTBF).  Coupled  with  maintainability,  it  impacts  availability  of  the  communications 
system.  MTBF  is  usually  measured  in  hours.  Military  standards  exist  to  describe 
component  specifications  and,  by  extension,  can  be  used  to  describe  system 
requirements. 

Reliability  may  imply  redundance  which  measures  duplication  of 
components.  A  high  reliability  requirement  coupled  with  low  MTBF  will  normally 
require  redundancy  which  will  usually  impact  system  life  cycle  cost  (both  initial 
procurement  and  supportability). 

Component  reliability  measures  may  depend  on  element  placement  in  the 
C  system.  Higher  priority  elements  will  normally  require  higher  restoral  ability, 
impacting  the  value  assigned  to  reliability. 

Link  reliability  expresses  an  assurance  that  communications  will  function 
accurately  [Ref.  8:  p.  2-4].  In  this  sense  transmission  efficiency,  receiver  sensitivity,  and 
receiver  selectivity  are  considered  quantitative  measures. 
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c.    Conclusion 

The  following  elements  can  be  used  in  defining  a  reliability  measure: 
•      Overall  Reliability  Requirement  (Measured  in  percentages) 

•  Component  MTBF  (in  hours) 

•  Redundancy  (No.  of  backup  components  required) 

•  Receive  Sensitivity  (ability  to  detect  signals) 

•  Receive  Selectivity  (ability  to  differentiate  signals) 

•  Transmission  Efficiency  (includes  SNR/Error  Detection  Techniques) 

•  Required  Bit-Error-Rate  (BER) 

•  Mean  Time  to  Repair  (MTTR) 
3.  Interoperability 

a.  Definition 

The  condition  achieved  among  communications  electronics  systems  or 
items  of  communications  electronics  equipment  when  information  or  services  can  be 
exchanged  directly  and  satisfactorily  between  them  and  or  their  users.  The  degree  of 
interoperability  should  be  defined  when  referring  to  specific  cases. 

The  ability  of  systems,  units,  or  forces  to  provide  services  to  and  accept 
services  from  other  systems,  units  or  forces  and  to  use  the  services  so  exchanged  to 
enable  them  to  operate  effectively  together.   (JCS  Pub  1) 

b.  Discussion 

Communications  interoperability,  while  seemingly  simple  to  define,  has 
been  characteristically  difficult  to  attain.    Interoperability  is  a  function  of: 

Equipment  compatibility; 

Interface  operating  procedures;  and, 

Message  formatting  and  design  standards. 
Interoperability  may  be  measured  with  respect  to  any  or  all  of  these  functions. 
Technical  Interface  Standards  consist  of  specifications  of  the  functional,  electrical,  and 
physical  characteristics  necessary  to  allow  the  exchange  of  information  across  an 
interface  between  different  tactical  C~\  systems  or  equipment  [Ref.  2:  p.  2-1]. 
Procedural  standards  consist  of  specifications  for  the  manner  of  accomplishing  the 
exchange  of  information  across  an  interface.   They  define: 

The  form  or  format  in  which  information  is  to  be  exchanged; 

the  prescribed  information  exchange  language,  syntax,  and  vocabularv  to  be 
used  in  the  information  exchange;  and, 
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interface  operating  procedures  that  govern  the  information  exchange  [Ref.  2:  p. 

(1)  Compatibility.  Elements  or  parameters  to  be  considered  when  ensuring 
communications  compatibility  include  modulation,  frequency  range,  range,  signalling, 
cryptographic  hardware  and  software,  and  interface  connectivity.  Of  the 
aforementioned  parameters,  interface  connectivity  is,  at  times,  the  most  difficult 
element  of  compatibility  element  to  achieve.  Intra  and  interservice  Command  and 
Control  Elements  (C~E's)  use  a  wide  variety  of  computer  and  radio  control 
equipments.  In  designing  a  system,  existing  terminal  devices  must  be  considered  for 
numerous  reasons,  not  the  least  of  which  is  cost.  DoD  has  a  stated  policy  to  minimize 
the  number  of  buffering,  translative,  or  similar  devices  to  achieve  interoperability 
[Ref.  9:  p.  2].  A  judicious  use  of  modems,  buffers  and  translaters  must  routinely  be 
designed  into  communications  architectures  to  ensure  interoperability. 

(2)  Message  Formatting  and  Design.  Message  formating  and  design 
features  are  specified  in  the  JCS,  JINTACCS  (Joint  Interoperability  of  Tactical 
Command  and  Control  Systems)  program  as  well  as  in  Technical  Interface  Design 
Plans  (TIDPs)  (Addressed  in  Chapter  IV).  Elements  are  combined,  in  an  approved 
sequence,  to  form  a  standard  message.  Once  it  is  determined  that  input  messages  to  a 
transmitting  device  match  output  messages  in  a  receiver,  compatibility  is  said  to  exist. 
Where  discontinuities  exist,  measures  are  taken  to  resolve  differences.  For  example,  if 
operationally  required  formats  do  not  exist  in  the  JINTACCS  system,  then  justification 
is  drawn  to  include  the  message  as  a  new  standard.  Once  this  justification  is  accepted, 
new  message  formats  are  derived.  A  process  wherein  this  is  accomplished  is  described 
in  Chapter  IV,  Technical  Interface  Concepts. 

(3)  Interface  Operating  Procedures.  Interface  operating  procedures,  while 
ultimately  linked  to  the  format  and  design  features  already  addressed,  are  developed  as 
a  result  of  Combined  and  Joint  Service  training  and  exercises.  These  require  agreement 
on  the  part  of  all  agencies  as  to.  ultimately,  the  method(s)  by  which  elements, 
commands,  and  forces  are  directed  or  controlled  in  a  tactical  environment.  There  are 
several  stumbling  blocks  to  acquisition  planners  as  well  as  operational  commanders. 
First,  achieving  a  unified  view  is  particularly  difficult  given  unit  and  service 
parochialism.  Next,  qualifying  or  quantifying  this  requirement  requires  extensive 
operational  tests  and;  or  simulation.  Finally,  tradeoffs  that  are  made  during  the 
acquisition  process  may  impact  reliability,  speed,  flexibility,  economic  factors,  or  even 
the  entire  project  success. 
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c.    Conclusion 

The   following   elements   can  be   used   in   quantifying   an  interoperability 


measure: 

•      Overall      Communications      Interoperability      Requirement 
Percentages) 


Measured      in 


Modulation  -  The  extent  to  which  both  equipments  are  capable  of 
operating  using  the  same  modulation  scheme 

Frequency  Range  -  The  extent  to  which  equipments  have  the  same  (or 
nearly  the  samel  frequency  ranee  and  tuning  capability  to  accommodate 
assigned  frequencies  (applicable  for  RF  systems) 

Ranee  -  distance  or  coverage  of  the  system  affected  bv  transmit  power, 
antenna  gain,  receive  sensitivity,  repeaters,  propagation  and  terrain 

Signalling  -  The  nature  of  such  types  as  analog  or  digital,  in-band  or  out- 
ofrband;"etc. 

Cryptographic  -  The  extent  to  which  hardware  is  compatible  with  the  radio 
or  wire  system.  Software  must  be  approved  for,  be  compatible  with,  and  be 
available'to  all  desired  users. 

Interface  Connectivity  -  The  extent  to  which  the  communications  system 
supports  each  element  specified  in  theproblem  definition  (Module  1  - 
MCES)  and  bounded  (in  Module  2  -  MCES). 

Message  Format  and  Design  -  The  extent  to  which  required  messages  meet 
existing  criteria  or  that  additional  standards  must  be  created. 

Interface  Operating  Procedures  -  again,  in  answering  the  Module  1 
requirements  and  Module  2  bounds,  tlfe  extent  to  which  all  elements  are  in 
agreement  as  to  direction  and  control. 

4.  Speed 

a.  Definition 

Speed  denotes  timeliness  in  the  flow  of  information  between  users  of 
communications  [Ref.  S:  p.  2-5].  Speed  is  a  communication  element  measure  of 
performance  supporting  the  timeliness  measure  of  effectiveness  of  the  C    system. 

b.  Discussion 

A  quantitative  measure  of  speed  is  based  on  operational  urgency.  Speed  is 
usually  defined  for  digital  systems  in  terms  of  bits-per-second  (BPS)  or  baud  rate.  It  is 
dependent  on  the  communications  means  chosen  and  the  efficiency  of  technology  and 
design.  Speed  is  also  controlled  by  procedures.  Personnel  training  and  adherence  to 
precedence  as  well  as  other  message  designators  may  impact  communications  speed. 
In  addition  to  BPS  and  Baud  rate,  speed  may  be  determined  by:  throughput,  switching 
rate,  routing  plan,  human  message  handling  speeds,  dialing  method,  precedence  levels, 
processor  speed  and  capacity;  and,  queueing  [Ref.  7:  p.  A-26J. 
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Grade-of-Service  (GOS)  for  switched  (circuit,  message,  and  packet)  systems, 

indicating  a  probability  of  a  call  (message)  being  blocked  or  delayed  more  than  a 

specified   interval,   could   also    be   used   as   a    measure   of  speed.     GOS    varies   from 

subjective  ratings  such  as  excellent,  good,  fair,  poor  or  unsatisfactory,  to  quantitative 

probability  calculations  based  on  the  following  generalized  equation  [Ref.  7:  p.  A-24]. 

GOS  =  f(T.C.R,A.D)  where: 

1  =  traffic  volume  bv  type  of  service  (in  erlanes) 

C  =  channel  capacity 

R  =  alternate  routing  capability 

A  =  call  or  message  arrival  probability  distribution  (assumed  to 

be  poisson  distributed  for  commercial  communications) 
D  =  channel  degradation 
c.    Conclusion 

The  following  elements  may  be  used  in  supporting  speed  as  a  measure  of 

performance: 

•      Overall  Required  Speed  (measured  in  time) 

BPS  or  Baud  Rate  Required 

Throughput 

Switching  Rate 

Routing  plan 

Human  message  handling  speeds 

Dialing  method  (touch-tone,  rotary  or  operator  assist) 

Precedence  levels 

Processor  speed  and  capacity 

Queuing 

GOS  required 

5.  Security 

a.  Definition 

Security  is  the  protection  resulting  from  all  measures  designed  to  deny 
unauthorized  persons  information  of  value  which  might  be  derived  from  the  possession 
and  study  of  communications,  or  to  mislead  unauthorized  persons  in  their 
interpretation  of  such  a  study  [Ref.  8:  p.2-4]. 

b.  Discussion 

The  four  elements  of  communications  security  (COMSEC)  are:  crypto 
security,  transmission  security,  emission  security  and  physical  security. 

Crypto  security  results  from  the  provision  of  technically  sound 
cryptosystems  and  their  proper  use  [Ref.  8:  p. 6-19].    In  acquisition  of  communications 
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systems  this  involves  working  closely  with  the  National  Security  Agency  (NSA),  the 
certifying  authority  for  new  systems  applications.  Crypto  security  measures  may 
impact  interoperability.  As  an  example,  a  crypto  system  in  use  on  one  type  of  HF 
radio  may  not  be  approved  for  use  with  a  new  design.  While  all  of  the  other 
compatibility  measures  may  match,  a  requirement  for  a  new  crypto  system  seriously 
impairs  interoperability,  perhaps  rendering  the  new  design  unsuitable.  The  requirement 
for  crypto  security  may  also  degrade  flexibility.  Cryptographic  material,  both  hardware 
and  software,  is  issued  with  the  realization  that  only  loss  of  the  software  will 
compromise  the  system  and  then  only  for  the  period  the  software  is  in  effect. 
Consideration  must  be  given  to  the  area  in  which  the  equipment  will  be  employed.  Use 
in  a  hazardous  region  may  require  limited  distribution  or  minimal  holding  of  the 
material  impacting  system  flexibility.  Alternatively,  a  system  applying  a  remote  keying 
scheme  may  be  more  costly  and  require  more  training  to  operate,  affecting  simplicity 
and  economy. 

Transmission  security  results  from  all  measures  designed  to  protect 
transmissions  from  interception  and  exploitation  by  means  other  than  crypto  analysis 
[Ref.  8:  p. 6-22],  commonly  referred  to  as  LPE,  LPI  (Low  Probability 
Exploitation  Intercept).  Limited  exploitation  relates  to  the  cryptographic  capability  to 
mask  the  information  content  of  the  transmission.  This  is  often  measured  by  the 
amount  of  time  necessary  to  decipher  the  text  without  a  key.  The  limited  probability 
of  intercept  measures  the  range  within  which  an  enemy  must  be  in  order  to  detect  and 
intercept  a  signal.  This  implies  knowledge  of  the  enemies  capabilities  and  intentions 
and  or  predicted  future  abilities  which  should  have  been  considered  in  the  Problem 
Formulation  and  System  Bounding  stages  of  the  MCES.  In  determining  the 
probability  of  intercept  or  effect  on  a  communications  system,  planners  will  use  such 
parameters  as;  range  (from  enemy  jammer,  receiver),  transmit  power  (jammer  and.  or 
friendly  transmitter),  type  of  signalling  and  modulation,  receiver  allowed  bit-error-rate 
(BER),  antenna  design,  and  propagation  factors  (including  terrain). 

Emission  security  refers  to  that  component  of  COMSEC  resulting  from 
measures  taken  to  deny  information  of  value  that  may  be  derived  from  intercept  and 
analysis  of  emanations  from  crypto  equipment  and  telecommunications  systems 
[Ref.  8:  p.  6-26].  Care  must  be  taken  in  systems  design  to  reduce  unintended 
emanations  from  tactical  equipments.  Such  signals  may  appear  as  electromagnetic 
radiation  from  constant  key  sources,  conducted  emanations,  powerline  modulation,  or 
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acoustic  emanations.  All  are  susceptible  to  interception  and  exploitation  either  to 
disclose  classified  information,  to  allow  direction  finding  of  transmitter  sites,  or  to 
permit  identification  of  electronic  order  of  battle  fingerprints  of  headquarters  elements. 
Adherence,  by  both  designer  and  operator,  to  TEMPEST  requirements,  established  by 
\SA,  should  effectively  reduce  the  unintended  emanations.  Simulation  and  operational 
testing  of  a  proposed  system  coincident  with  existing  systems  should  aid  designers  and 
operators  in  identifying  and  overcoming  architectural  weaknesses  relative  to  emission 
security. 

Physical  security  refers  to  the  component  of  COVISEC  resulting  from  all 
physical  measures  taken  to  safeguard  classified  equipment,  material,  and  documents 
from  access  to  or  observation  by  unauthorized  persons  [Ref.  8:  p. 6-27].  Physical 
security,  like  crypto  security,  impacts  the  design  process  relative  to  flexibility  and 
economy.  The  requirement  to  safeguard  systems  and  software  may  impact  universal 
usage  and/or  drive  acquisition  costs  past  on  acceptable  level. 
c.    Conclusion 

The  following  parameters  may  be  used  in  describing  security  as  a  measure 
of  performance: 

•      Overall  Security  Requirement 

Economic  (Cost)  constraint 

Crypto  (hardware/software  compatibility)  requirement 

Required  probability  of  intercept/exploitation 

Known  or  projected  enemy  capabilities 

TEMPEST  requirement s) 
6.  Flexibility 

a.  Definition 

Adaptable  to  change  (Random  House  Dictionary).  The  ability  to  support 
a  wide  dispersion  of  units  under  adverse  or  varying  conditions  [Ref.  8:  p.  2-5]. 

b.  Discussion 

The  Marine  Corps  definition  is  limited  in  that  it  implies  a  universal  use  and 
is  directed  more  towards  the  planning  and  integration  of  all  systems  to  support 
command  and  control.  It  requires  acquisition  sponsors  to  consider  the  combined 
effects  of  proposed  and  existing  systems  and  to  study  the  results  of  operational  tests 
before  committing  to  full-scale  production. 
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Because  of  the  versatile  nature  of  modern  warfare,  flexibility  also  infers 
mobility,  or  the  ability  to  retain  command  and  control  while  on  the  move.  This 
influences  size,  weight  and  transportability  of  equipment,  personnel  and  logistics  to 
support  the  system. 

The  dictionary  definition  indicates  an  ability  to  change  by  expanding, 
contracting  or  reorganizing  the  service  provided.  It  may  also  allow  change  of  modes 
within  a  specified  range  of  operation.  For  instance;  an  error  control  may  be  relaxed  for 
digitized  voice  and  increased  for  data  transmission.  Or,  in  order  to  improve  emission 
security,  transmission  power  may  be  tunable  to  the  least  amount  necessary  to  ensure 
reception  limiting  the  range  of  interception. 
c.    Conclusion 

Flexibility  determinants  include: 
Ability  to  expand,  contract,  or  reorganize  service 
Choices  of  bit  rate 
Choice  of  transmitter  power 
Choice  of  error  control 
Mobility  factors 
7.  Survivability 

a.  Definition 

All  measures  taken  to  prevent  disruption  of  communications  by  1 )  enemy 
interference  or  natural  disaster  [Ref.  8:  p.  2-7]  and,  2)  measures  the  capability  to 
survive  conventional,  nuclear  and  CBR  attack  for  continuity  of  operation  under  the 
worst  probable  conditions  of  conflict  [Ref.  7:  p.  A-8]. 

b.  Discussion 

As  a  function  of  the  sum  of  the  aforementioned  factors,  the  survivability 
measure  must  be  evaluated  as  constrained  by  budgetary  considerations. 

Disruption  by  enemy  interference  has  been  covered,  albeit  obliquely,  under 
transmission  security.  The  same  parameters,  ie.,  range,  transmit  power,  type  of 
signalling  and  modulation,  BER,  antenna  design,  and  propagation  factors,  are  used  to 
determine  the  effect  of  communication  jammers.  The  use  of  similar  design  parameters 
do  not  adversely  affect  measure  independence.  The  equations  used  to  derive  the 
measures  are  unique. 

Measures  to  prevent  natural  and  or  man-made  disaster  include  such 
elements    as    redundancy    (outlined    under    Reliability)    and    design.     Design   criteria 
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describe  the  physical  characteristics  of  equipment  necessary  to  withstand  chemical, 
nuclear  and  conventional  damaging  effects.  Such  requirements  inherently  drive-up 
costs  as  physical  properties  are  reinforced  and  electronic  components  are  built  or 
backed-up  to  withstand  the  affects  of  electromagnetic  pulse  (EMP). 

Survivability  is  also  enhanced  by  the  Mobility  factors  listed  under 
Flexibility. 

c.   Conclusion 

Survivability  determinants  include: 

•  Overall  Survivability  Requirement 

•  Economic  (cost)  constraint 

•  Redundancy  (Number  of  backups  required) 

•  Range 

•  Transmit  power 

•  Signalling  and  modulation 

•  BER 

•  Antenna  design 

•  Propagation  factors  (including  terrain  and  weather) 

•  Mobility  factors 
8.  Simplicity 

a.  Definition 

The  ease  of  access  and  operation  for  users,  and  the  ease  of  installation, 
operation  and  maintenance  for  operators  [Ref.  8:  p.  2-7]. 

b.  Discussion 

Simplicity,  easy  to  define,  is  becoming  characteristically  ignored  in  new 
systems  development.  The  technology  that  allows  a  reduction  in  operations  manning, 
at  times,  increases  the  demand  on  communications  managers  and  personnel.  Thus, 
from  both  budgetary  (in  terms  of  manpower)  and  simplicity  perspectives,  trade-offs 
must  be  made  in  order  to  find  the  optimum  mix  between  operations  and 
communications. 

Simplicity  may  also  affect  flexibility.  A  flexible  system,  one  with  many 
options,  may  be  complex  to  operate  and  maintain,  yet  meet  the  definition  demands  of 
Module  1  (MCES). 

c.  Conclusion 

Simplicity  considerations  include: 

•  Simplicity  requirement;  balanced  against, 


•  Budgetary  (Manpower  training)  impact 

•  Flexibility  and  mission  need  statements 
9.  Economy 

a.  Definition 

Economy  results  from  actions  taken  to  ensure  the  best  use  of  available 
communications  personnel,  equipment  and  supplies  etc. (Random  House  Dictionary). 

b.  Discussion 

While  previously  mentioned  as  a  constraining  parameter  for  other 
measures,  economy,  or  a  degree  of  economy,  should  be  considered  as  a  measure  itself. 
Given  a  cost  constraint,  the  acquisition  manager  must  balance  the  bounded  mission 
need  against  the  cost  of  acquiring  the  measures  necessary  to  support  the  requirement. 
Hence,  the  budget  is  compared  with  the  sum  of  the  costs  of  supporting  each  measure. 
Simply  put.  if  cost  exceeds  budget,  the  manager  must  justify  a  request  for  increased 
funds,  reiterate  the  MCES  process,  or  recommend  project  cancellation  or  re-definition. 

c.  Conclusion 

Economy  requires  conciliation  between  the  project  and  existing  demands 
for  scarce  resources  (money,  personnel  and  equipment).  Given  a  budgetary  or  cost 
restriction,  the  decision  maker  must  make  even'  effort  to  stay  within  these  guidelines 
while  ensuring,  first  and  foremost,  that  the  mission  requirement  (Module  1)  is  resolved. 

E.  MEASURE  INTERACTION 

The  introduction  to  the  previous  section  alluded  to  potential  interrelationships 
between  measures.  Figure  3.1  graphically  portrays  these  associations.  The 
dependencies  or  connections  are  represented  by  the  lines  drawn  between  the  measures. 
Arrows  indicate  flow.  While  it  may  certainly  be  debated  that  all  measures  are  related, 
one  to  another,  the  links  shown  depict  the  author's  subjective  judgement  of  the  most 
important  effects.  Other  analytical  means,  beyond  the  scope  of  this  thesis,  are  needed 
to  determine  degrees  of  interaction.  Sensitivity  analysis  or  a  database  of  past 
experience  are  two  possible  ways  to  define  measure  interplay. 

F.  CONSIDERATIONS 

Numeric  values  approaching  100%  are  desired  for  some  of  these  measures 
(reliability,  interoperability,  security,  flexibility  and  survivability).  While  verbal  merits 
such  as  "fastest"  (speed),  "least  expensive"  (economy),  and  "uncomplicated"  (simplicity) 
would   describe    others.     However,    use   of  such   terms   is   not    only   impractical    but 


33 


Reliability 


Speed 


Economy 


Simplicity 


Security 


Survivability 


Flexibility 


Tigure  3.1     Measures  Interactions. 

unattainable.  When  specifying  these  measures,  consideration  must  be  given  to  their 
underlying  parameters  and  overall  system  requirements.  For  example,  while  it  may  be 
nice  to  have  a  system  that  will  operate  at  5  megabits-per-second,  to  cover  every 
eventuality,  if  the  computer  processing  speed  at  the  terminal's  input  and  output  is  1000 
bits-per-second.  too  much  slack  has  been  required  in  the  variable.  Relative  to  the 
previous  discussion,  this  may  adversly  affect  cost  with  no  necessitated  gains.  In  short, 
the  quantitative  or  qualitative  descriptions  required  must  represent  reality. 

Another  consideration  involves  a  standard,  or  nearly  standard  means  of  attaining 
values  for  measures.  The  Marine  Corps'  Technical  Interface  Concepts  (Chapter  V) 
represents  an  attempt  at  regulating  this  process.  By  describing  the  statics  involved,  the 
process  between  elements,  and  comparing  these  with  existing  integrated  systems,  the 
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process  becomes  regulated.  Anomalies  require  justification  for  addition  to  existing 
databases.  Similarities  aid  in  starting  the  process  of  detailed  requirements  listings.  If. 
for  example,  a  similar  task  (process)  is  required  of  other  elements  (statics)  within  the 
database,  decomposition  may  well  lead  to  physical  properties  already  used  to  support 
such  a  function.  These  values  lend  a  starting  point  for  requirements.  More  important, 
the  point  is  already  employed  by  the  organization,  in  this  case  The  Marine  Corps,  and 
adherence  to  such  a  level,  while  perhaps  not  imperative  in  this  specific  application,  may 
well  serve  to  assist  future  endeavors.  Suppose  the  message  standard  leads  to  a 
bandwidth  specification  of  5  Mhz  impacting  speed,  reliability,  security,  and  economy 
(for  this  example).  While  not  a  critical  or  required  measure  in  this  case,  the  designated 
parameter  affects  (positively)  interoperability  thereby  allowing  for  possible  expansion 
of  the  desired  system  into  other  applications. 

Relative  importance  of  measures  at  the  acquisition  management  level  is 
dependent  ultimately,  and  optimally,  on  support  of  the  mission  need  described  in 
Module  1.  This  is  determined,  in  the  final  analysis,  on  performance  under  actual 
operating  conditions.  However,  decisions  involving  performance  and  effectiveness  must 
be  made  much  earlier  in  the  process.  Lacking  'fool-proof  means  of  weighting 
measures,  the  decision  maker  must  make,  at  times  subjective,  judgements  as  to 
associated  merit.  This  may  again  require  an  iterative  process.  Political  reality 
currently  mandates  interoperability,  reliability,  and  economy  as  critical  measures.  A 
'generic'  ranking  is  certainly  unwise  and  description  of  decision  theory  is  beyond  the 
scope  of  this  thesis.  One  means,  or  consideration,  is  certainly  worth  mentioning. 
While  seemingly  self-evident,  the  decision  maker  must  assure  amelioration  of  both 
operator  and  systems  engineers  in  the  process.  Failure  to  consider  the  input  of  one  or 
the  other  may  lead  to  disastrous  consequences. 

Two  final  points  need  to  be  stressed.  While  the  measures  (MOPs  in  this  case) 
may  be  interrelated,  the  equations  used  in  defining  them  are  not.  The  parameter 
'range'  may  be  used  in  determining  both  'speed'  and  'security'.  However,  the 
formulation  of  these  must  be  kept  separate.  Mathematically,  while  security  may  be  a 
function  of  range  (security  =  f(range....))  and  speed  is  a  function  of  range  (speed  = 
grange....)),  the  functions  are  unique  even  if  the  design  parameters  are  equal. 

Finally,  both  quantitative  and  qualitative  standards  have  merit  in  the  analysis. 
While  numeric  values  may  be  desirable,  they  are  not  always  attainable.  Verbal 
descriptors  may  point  to  debate  and  subjective  judgement;  however,  a  measures'  merit 
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is  not  to  be  based  on  an  ability  to  assign  an  arithmetic  rate.  The  measure  is  necessary 
because  it  aids  in  characterizing  the  system.  Omitting  qualitative  measures  would 
result  in  an  incomplete  description. 

G.       SUMMARY 

This  chapter  has  defined  and  described  generic  measures  of  performance  to  be 
used  in  analysis  of  a  communications  system.  As  part  of  the  description,  a  listing  of 
parameters  was  derived  to  support  derivation  of  each  measure.  Table  4  reflects  the 
results.  While  perhaps  not  all  inclusive,  it  represents  a  point  of  departure  for  system 
analysis. 
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TABLE  4 
GENERIC  MEASURES 


Measure, 
Reliability 


Interoperability 


Speed 


Security 


Flexibility 


Survivability 

Simplicity 
Economy 


Parameters 
Component  MTBF,  Redundancy,  Receive 
Sensitivity,  ReceiveSelectivity,  Transmission 
Efficiency, Required  BER,  Mean  Time  to 
Repair 

Modulation,  Frequency  Range,  Range, 
Signalling,  Cryptographic,  Interface  Connectivity, 
Message  Format  and  Design,  Interface 
Operating  Procedures 
BPS  or  Baud  Rate  Requlred.Throughput, 
Switching  Rate,  Routing  Plan,  Human 
message  handling  speeds,  Dialing  method, 
Precedence  levels,  Processorspeed  and 
capacity,  Queuing,  GOS  Required 
Economic  (cost)  constraint,  Crypto 
(hardware/software  compatibility) 
requirement,  Required  probability  of 
Intercept/exploitation,  Known  or  projected 
enemy  capabilities,  TEMPEST  requlrement(s) 
Ability  to  expand,  contract,  or  reorganize 
service,  Choices  of  bit  rate,  Choice  of 
transmitter  power,  Choice  of  error  control, 
Mobility  factors 

Economic  (cost)  constraint,  Redundancy, 
Range,  Transmit  power,  Signalling  and 
modulation, BER,  Antenna  design, 
Propagation  factors,  Mobility  factors 
Budgetary  (manpower/training)  Impact, 
Flexibility  and  mission  need  statement 
Conciliation  between  the  project  and  existing 
demands  for  scarce  resources. 
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IV.  TECHNICAL  INTERFACE  CONCEPTS 
INTRODUCTION 


Powerful,  sophisticated,  command  and  control  (C2)  svstems  that  exploit  a  rapidlv 
expanding  technological  base  are  becoming  realities:' yet.  issues  concerning  their 
integration  into  the  larger  context  of  a  command  and  control  architecture  remain 
unresolved.  Military  planners  require  clearlv  defined  standards  of  compatibility 
and  interooerabilitv'to  retrofit  fielded  systems,  modify  those  currently  in  design, 
and  plan  for  future  ones.  A  major  goal  of  the  Department  of  Defense  is  "to 
provide  these  planners  with  accurate,  detailed  information  about  their  particular 
svstem  requirements,  about  the  interrelationship  of  their  tactical  system  with 
o'ther  systems,  and  about  the  impact  that  system  will  have  on  the  architecture  as 
a  whole. 


Achievement  of  this  goal  requires  development  of  a  suitable  method  for 
identifying,  capturing,  organizing,  and  accessing  information  necessary  to 
describe  current  and"  projected  svstems.  Succinctly  stated,  the  military  must 
develop  a  usable  model  of  its  C2  architecture.  This  model  must  provide  two 
essential  premises.  First,  it  must  answer  detailed  questions  about  the  C2 
structure,  providing  a  view  of  that  structure  in  its  totality  as  well  as  its 
particulars.  Second,  it  must  provide  input  to  programs  engaged  in  dynamic 
analysis  such  as  wargame  scenarios  and  network,  loading  studies  [Ref.  10]. 


This  quote  provides  a  concise  statement  of  DoD  and  Marine  Corps'  objectives 
relative  to  managing  command  and  control  architectures.  Most  of  the  references  cited 
in  this  chapter  have  to  do  specifically  with  inter  and  intraoperability,  yet  in 
standardizing  interoperability  and  acquisition  management  processes  and 
responsibilities,  it  also  provides  a  systematic  mechanism  for  compliance  with  the 
bounding,  process  definition,  integration,  and  data  generation  modules  of  the  MCES. 
This  chapter  will  describe  the  Technical  Interface  Concepts  (TIC)  and  Marine  Corps 
Interoperability  Management  Plan  (IMP)  principles  applicable  in  the  MCES 
framework,  pertinent  to  communications  acquisition  and  management. 

B.       PURPOSE 

The  overall  objective  of  the  Interoperability  Management  Plan  (IMP)  is  to 
ensure  the  exchange  of  critical  tactical  information.  This  is  accomplished  at  two  levels: 
first,  on  a  Marine  Corps  unique  level  (referred  to  as  intraoperability)  then,  on  a  joint  or 
combined  level  between  Marine  Air  Ground  Task  Forces  (MAGTFs)  and  other  U.S.  or 
Allied  commands.  The  IMP  centralizes  and  standardizes  procedures  for  management 
activities.   These  procedures  aim  to  accomplish  the  following: 
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•  Identify  the  manner  in  which  existing  and  new  interoperability  requirements  and 
standards  are  identified,  defined,  standardized,  and  documented. 

•  Facilitate  the  implementation,,  verification,  testing,  and  certification  of  those 
standards  in  developing  tactical  data  systems  (TDSs)  and  interconnecting 
equipment. 

•  Prescribe  coordination  between  the  various  configuration  management  bodies 
and  activities  that  control  modifications  to  requirements,  standards,  TDSs,  and 
interconnecting  equipment. 

•  Ensure  that  interoperability  program  requirements  are  adequately  planned  for 
and  funded  [Ref.  if:  p.  1-3J!         ~ 

The   Technical   Interface   Concepts  (TIC)   document   identifies   and   establishes 

Marine   Corps   command,    control,    and   communications   (C  )    facility   and    systems 

operational  interface  requirements  for  both  current  and  future  periods.    It  is  a  baseline 

from    which    other    USMC    interoperability    technical    documents,    standards,    and 

specifications  are  developed  [Ref.  12:  p.   1-1].    The  objective  of  the  TIC  is  to  provide 

the  framework  to  ensure  that  fielded  Marine  Corps  Tactical  Command  and  Control 

Systems  (MTACCS)  are  compatible,  interoperable,   and   operationally  effective.     In 

keeping  with  the  IMP.  MTACC  systems  are  first  intraoperable,  then  interoperable  with 

other  than  Marine  systems.    Compatibility  with  other  service  systems  is  to  be  attained 

through  application  of  the  JINTACCS  (Joint  Interoperability  of  Tactical  Command 

and  Control  Systems)  program. 

C.  PHILOSOPHY 

The  MTACCS  concept  of  standardizing  automated  interfaces  has  been  to  :  (1) 
standardize  at  the  "transmission  format"  level,  (2)  leave  the  man-machine  interface  to 
be  resolved  by  individual  system  requirements  and  constraints,  and  (3)  to  bit-code 
messages  and  data  items.  The  JINTACCS  concept  has  evolved  to  one  of 
standardizing:  (1)  both  at  the  machine  and  human  levels,  (2)  for  voice,  record,  and 
automated  interfaces,  and  (3)  character  codes  for  data  items.  In  order  to  maintain 
compatibility  in  JINTACCS  Allied  operations,  MTACCS  systems  engineering  has 
maintained  compatibility  at  the  data  item  level  and  developed  message  conversion 
protocols  for  specific  interfaces  [Ref.  12:  p.  1-2]. 

D.  METHODOLOGY 

This  section  will  address  the  specific  set  of  procedures  designed  to  determine 
specifications  and  standards  from  validated  operational  (or  mission)  requirements.  The 
mission  requirements  formulation  is  the  responsibility  of  Mission  Area  Sponsors. 
These   sponsors   conduct    Mission   Area   Analyses  (MAAs)  in   an   effort   to   validate 
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current  requirements  and  to  define  future  operational  needs.  A  command  and  control 
architecture  is  then  developed  to  facilitate  the  aggregation  of  associated  elements 
required  to  support  mission  needs.  The  basic  entities  of  a  C  architecture  are 
illustrated  in  Figure  4.1  (author's  concept)  and  described  below  [Ref.  11:  p.  3-3]. 


Figure  4.1     Marine  Corps  Cz  Architecture. 

1.  Operational  Facilities 

Otherwise  referred  to  as  OEs  (Command  and  Control  Elements)  in  the 
parlance  of  Joint  planners,  Operational  Facilities  (OPFACs)  are  those  elements  tasked 
with  performing  the  C"  Process  functions  described  in  Chapter  II  (Table  4).  Each  C^E 
consists  of  equipment,  communications,  facilities,  personnel,  and  procedures  required 
to  assist  the  commander  in  carrying  out  his  C    responsibilities.    They  vary  widely  in 


40 


size  and  complexity  from  a  single  forward  observer  (FO)  to  a  large,  integrated  Fire 
Support  Coordination  Center  (FSCC). 

2.  Tasks 

OPFAC  or  C^E  tasks  are  those  functions  performed  by  the  C^E  requiring  it 
to  exchange  information  with  other  C"Es.  They  are  extracted  from  existing  documents 
reflecting  approved  doctrine,  procedures  and  techniques  contributing  to  the  overall 
command  and  control  function. 

3.  Message  Elements/Standards 

Elements  are  the  fundamental  details  of  information  used  to  construct 
messages.  Message  elements  are  composed  of  standard  Data  Field  Identifiers  (DFIs), 
Data  Use  Identifiers  (DL'Is)  and  Data  Items  (DIs).  These  standards  are  used  to 
implement  information  exchange  in  Marine  Corps  TDSs.  The  elements  are  collected 
and  formed  into  standard  messages  and  documented  in  the  Technical  Interface  Design 
Plan(TIDP). 

4.  Equipment  and  Link  Requirements 

C~Es  relate  to  one  another  as  either  source  or  sink  {sender  or  receiver)  of  the 
messages  described  above.  This  relation  implies  a  requirement  to  establish  a 
communications  link  in  support  of  information  flow.  The  link  is  established  using 
TDSs  interconnected  with  communications  equipment,  each  of  which  can  be 
characterized  by  their  functions.  Communications  links  are  defined  in  terms  of 
operational  characteristics  and  constrained  by  technical  factors.  Ultimately,  the  link 
requirements  are  specified  in  terms  necessary  to  support  mission  needs.  Compliance 
with  these  needs  allows  specific  description  of  the  link  and  its  associated  equipment. 

5.  Protocol  Standards 

Protocols  are  the  rules  or  procedures  by  which  information  is  transferred 
through  systems,  interconnecting  equipments,  and  networks.  Marine  Tactical  System 
(MTS)  protocols  are  defined  by  an  eight-layered  reference  model  beginning  with  the 
transmission  media  and  ending  with  user  application.  The  model  and  standards  are 
documented  in  the  TIDP. 

6.  Message  Exchange  Occurrences 

A  command  and  control  architecture  is  typically  represented  as  a  Data- Flow- 
Diagram  (DFD).  The  circles  representing  nodes  and  the  connecting  lines 
communications  links.  A  specific  node  in  a  C  network  may  be  comprised  of  one  or 
more  C^Es.    For  example,  an  Infantry  Battalion  node  may  be  made  up  of  Fire  Support 
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Coordination  Center  (FSCC)  and  Combat  Operations  Center  (COC)  C  [Is.  In  keeping 
with  the  previous  discussion  of  architectural  elements,  the  lines  must  also  represent 
messages  to  be  transmitted  along  the  link.  Without  the  message  requirement  the  link  is 
idle.  The  most  basic  network,  then,  consists  of  two  (."'lis,  a  link,  and  a  message  that 
transports  information  along  the  link.  This  relation  is  portrayed  in  Figure  4.2. 
Limiting  the  description  further,  to  the  transmission  of  a  single  message,  requires  a 
discrete  information  transfer.  This  is  termed  a  Message  Exchange  Occurrence  (MHO). 
Validated  MEOs  establish  a  requirement  for  interoperability  and  at  the  same  time  a 
system  requirement  in  support  of  the  basic  mission  need. 


SENDER 


MESSAGE 


LINK 


A   GENERIC    EXAMPLE 


CALL  FOR  FIRE 


VHF    RADIO   (ANALOG) 


A  SPECIFIC  EXAMPLE 


RECEIVER 


Figure  4.2     Message  Exchange  Occurancc. 


E.       IMPLEMENTATION 

A  listing  of  all  validated  MEOs  is  useful  in  portraying  an  architecture  as  it  exists 
in  its  "potential"  state.    In  order  to  model  the  C"  process  in  a  specific  "kinetic"  state. 
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order  must  be  subscribed  to  the  MEOs  describing  flow  of  C"  activity  as  a  sequence  of 
events  [Ref.  10].  The  modelling  process  is  illustrated  in  Figure  4.3.  The  model  can  be 
used  to  define  specific  measures  of  effectiveness  and  then  validate  the  system  support 
of  mission  need.  Even  a  superficial  understanding  of  military  structure  would  suggest 
to  the  reader  that  a  listing  of  MEOs  is  quite  extensive.  This  section  will  explain  how 
MEOs  are  derived,  used  to  build  a  network,  and  used  to  model  command  and  control. 
This  description  follows  closely  the  work  of  Pipho  [Ref.  10]. 
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Figure  4.3     MEO  Chain. 

1.   Information  Base 

1  he  number  of  MFOs  is  seemingly  limitless.  Many  pages  would  have  to  be 
written  to  effectively  capture  the  information  content  of  all  MFOs.  Screening  the 
potential  exchange  capabilities  and  requirements  to  find  matches  or  similarities  for 
potential  architectures  would  be  a  grueling  task.  An  automated  database  would 
expedite  this  process  improving  management  of  both  existing  and  potential  C    systems. 

I  he  Marine  Corps  Interoperability  Database  (IDB)  is  being  designed  to 
provide  improved  management,  integrity,  and  communication  of  inter  intraoperability 
information.    The  IDB  will  provide  the  automated  tools  to: 
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standardize  and  centralize  inter  intraoperability  data; 

manage  proposed  changes  to  interoperability  requirements  and  standards; 

automate  and  manage  the  documentation  process  (TIC,TIDP); 

automate  compliance  tracking;  and, 

coordinate  between  interoperability  requirements  and  standards. 
Additionally,  a  fully  functional  IDB  will  provide  a  basis  for  the  implementation  of 
future  applications  such  as: 

•  simulation  of  inter,  intraoperability  scenarios  under  battlefield  conditions;  and, 

•  determine  alternative  communication  interfaces/configurations  [Ref.  13:  p.  3]. 

The  first  step  in  developing  the  IDB  is  to  identify  and  describe  the  basic 
2 
components  that  define  the  C    architecture.    Then  the  relationships  that  exist  between 

these  components  are  specified  and  entered  into  the  base  of  information. 

At  the  most  general  level,  the  C    architecture  components  are: 

•  C2Es  (OPFACs) 

•  C  E  tasks 

•  OE  resources 

2 

•  Information  required  to  perform  C  E  tasks 

•  Communication  capabilities  to  support  the  exchange  of  information  [Ref.  10]. 
Each  of  these  have  been  previously  described.    Figure  4.4  shows  this  set  of  components 
and  their  relationships.   OEs  have  two  kinds  of  resources:  people  and  equipment.   The 
degree    to    which    people    or   equipment    are    employed   depends    on    the    degree    of 
automation  involved. 

2.  Process 

The  Data  Flow  Diagram  (DFD)  is  the  primary  tool  used  to  illustrate  the 
major  components  of  the  IDB  and  to  systematically  decompose  major  functions  to 
their  basic  level.  The  function  being  described  is  the  MEO.  Its  elements  include:  the 
C  E,  message,  and  link. 

a.   Deriving  C  Es 

2 
C  Es  are  identified  by  name,  location  within  the  organization,  and  by  tasks 

they    perform.     Titles,    such   as   "fire   direction    center,"    simultaneously   identify   the 

Element  and  give  some  idea  of  their  function.    These  titles  become  progressively  more 

descriptive,  identifying  branch  and  echelon  (e.g.  infantry  regiment  fire  direction  center) 

and  joint  or  combined  level  (including  service  and  nation).   A  OE  is  specified,  then,  by 

organization  (or  unit),  branch,  echelon,  service,  and  country. 
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(perform) 


(require) 
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Figure  4.4     Components  of  C    Architecture  and  Their  Relationships. 

The  OF  is  the  processing  component  of  the  system.  It  performs  a  transfer 
function  processing  input  and  changing  it  to  output.  This  process  is  illustrated  in 
Figure  4.5.  The  Input-Process-Output  (IPO)  function  is  presented  as  both  information 
and  signal  processing. 

b.    Deriving  Message  Standards 

">  ") 

A  OF  is  viewed,  then,  as  a  O  system  component  whose  function  is  to 

~> 
process    information.     One    OF    may    receive    raw    intelligence    information    in    an 

incoming  message.    This  information  is  processed  by  extracting  pertinent  information 

in  terms  of  an  intelligence  assessment.    This  assessment  is  then  distributed  to  other 

OFs  as  an  update  in  an  outgoing  message.    The  transfer  function  can  be  described  in 

terms  of  the  tasks  being  performed.    An  analysis  of  these  tasks  suggest  the  information 

required  by  the  processing  OE.    A  decomposition  of  a  C  E  task  results  in  a  set  of 

subtasks  that  retain  the  basic   IPO  structure  at  a  lower  level.    Just  as  information 
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Figure  4.5     IPO  Model. 

packaged  in  a  message  feeds  the  general  task,  inlormation  elements  feed  the  OE 
subtasks.  these  elements  can  be  correlated  with  standard  message  elements.  The  set  of 
message  elements  reflects  the  information  requirement  necessary  for  all  the  subtasks 
reflected  in  the  general  task.  By  labeling  this  set,  an  appropriate  message  standard  is 
specified. 

To  illustrate  the  decomposition  process,  consider  a  hypothetical  situation  in 
which  a  tactical  air  operations  center  (TAOC)  must  alert  a  light  anti-air  missile 
(LAAM)  battalion  combat  operations  center  (LAAM  BN  COC)  to  the  possibility  of 
engagement  with  enemy  aircraft.  The  TAOC  must  determine  what  message  will  convey 
completely  the  information  required  by  the  LAAM  BN.  A  tactical  alert  will  invoke  a 
set  of  procedures  at  the  LAAM  BN  COC.  The  COC  must  perform  the  subtasks  listed 
in  Table  5.  These  tasks  govern  the  information  required  from  the  TAOC.  Using  the 
Marine  Corps  Message  Element  Dictionary  (MED),  standard  elements  of  information 
can  be  derived,  called  Data  Field  Identifiers/Data  Use  Identifiers  (DFI/DUl)(Shown  in 
Table  6). 

If  this  particular  combination  of  standard  message  elements  is  in  the  Marine  tactical 
system's  message  inventory,  it  should  be  used.  If  not,  the  required  elements  are 
enumerated  and  submitted  as  a  proposed  standard  for  this  particular  tactical  function. 
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TABLE 

5 

AIR  ALERT  SUBTASKS 

SUBTASK  NUMBER 

SUBTASK  DESCRIPTION 

Subtask 

1  

assign  a  track  number  to  the 
tactical  alert 

Subtask 

2  

classify  the  alert  in  terms  of  its 
track  type 

Subtask 

3  

record  the  time  of  the  event 

Subtask 

4  

classify  the  aircraft  In  terms 
of  threat  type 

Subtask 

5  

estimate  flight  size 

Subtask 

6  

record  the  bearing 

Subtask 

7  

record  the  range 

Subtask 

8  

record  the  altitude 

Subtask 

9  

record  the  velocity 

Subtask 

10 

issue  command  instructions 

TABLE  6 
DFI/DUI  BREAKDOWN 


INFORMATION  ELEMENTS 

Track  number 

Track  type      

Threat  time    , 

Threat  type    

Flight  size  estimate 

Track  bearing  

Track  range    

Track  altitude 

Track  velocity  

Command  action  


CORRESPONDING  DFI/DUI 

E618/001 
E090/001 
C051/165 
E529/001 
E901/001 
E494/011 
E499/003 
E491/170 
E233/001 
E905/001 
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If  the  task  description  is  incomplete,  the  user  or  cognizant  doctrinal  agency  initiates 
action  to  correct  it.  This  assures  that  operational  requirements  drive  message 
standards. 

c.    Deriving  Link  Standards 

Information  is  generally  transmitted  to  a  C  E  through  an  electronic  signal. 
The  message  (Text)  is  entered  into  a  converting  device  at  the  input,  changed  to 
electronic  format  and  passed  through  a  string  of  equipment  to  the  next  C  E,  Here  it  is 
translated  into  the  original  textual  form.  Input  and  output  requirements  for  each 
electronic  device  in  the  string  are  expressed  technically  as  equipment  specifications. 
Matching  the  input  text  to  the  output  text  specifies  compatibility  for  the  link.  Figure 
4.6  characterizes  the  communications  system  and  illustrates  signal  interface 
requirements.  By  correlating  the  specifications  of  a  system  with  these  standards,  the 
signal  interface  requirements  are  satisfied.  The  technical  specifications  define  the 
standard  for  the  C  E  link.   An  occurrence  of  this  link  is  recorded  in  the  MEO. 
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Figure  4.6    Communications  System. 
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OE  links  are  usually  constrained  by  the  environment  and  context  dictated 
in  the  mission  requirement.  These  operational  factors  include  determinants  like  range 
and  security.  These  restrictions  also  help  refine  the  technical  specifications  leading  to  a 
OE  link  standard.  Requirements  are  successively  broken  down  into  lower  levels  of 
detail  through  engineering  analysis.  If  no  system  or  equipment  set  exists  to  support 
the  link  requirement  a  circuit  standard  is  adopted  as  a  set  of  design  specifications  for 
the  system. 

3.  Network  Construction 

The  MEO  is  the  basic  network  building  block.  A  complete  set  of  MEOs 
produces  the  C  Network.  The  proper  association  of  MEOs  is  crucial  to  the 
construction  of  a  network  to  be  used  as  the  model  for  command  and  control.  While 
the  MEO.  by  definition,  describes  a  direct  transfer  of  information,  at  times  the 
exchange  may  transpire  between  non-adjoining  C  Es.  To  accommodate  this 
eventuality,  the  concept  of  a  virtual  message  exchange  occurrence  (VMEO)  is 
introduced.  The  VMEO  denotes  a  path  from  the  source  OE  to  the  sink  OE  through 
one  or  more  intermediate  OEs.  In  essence  the  VMEO  is  simply  a  chained  MEO  as 
shown  in  Figure  4.3. 

Command  and  control  flow  diagrams  (C  FDs),  a  specific  application  of  data 
flow  diagrams  (DFDs),  are  constructed  using  the  doctrinal  studies  described  in  mission 
area  analysis.  The  OFDs  represent  pictorially  the  flow  of  CJ  activity  in  the  network. 
Figures  4.7  and  4.8  combined  with  Tables  7  and  8  summarize  the  network  design 
process. 

F.       SUMMARY 

The  interoperability  database  will  provide  a  valuable  tool  for  planners  and 
managers  to  standardize  description  of  the  Marine  Corps  command  and  control 
architecture.  Consistent  application  of  the  MEO  concept  in  the  IDB  will  help  ensure 
interoperability  and,  at  the  same  time,  should  reduce  the  procurement  of  redundant  C 
systems.  Driven  by  mission  needs,  the  Technical  Interface  Concepts  is  in  keeping  with 
DoD  direction  discussed  in  Chapter  II  under  Problem  Formulation.  The  use  of 
Message  Exchange  Occurrences  follows  closely  the  system  bounding,  process  definition 
and  integration  modules  of  the  MCES.  Finally,  the  MEO  description  available  in  the 
IDB  allows  for  data  generation  (Module  6)  and  aggregation  following  the  outline  of 
System  Effectiveness  Analysis  which  follows. 
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Figure  4.7     OFD  for  Direct  Support  Artillery  Mission  (DSAM). 
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TABU:  7 
MliO  SCI  FOR  DSA.M 


MEO 

SOURCE  C2E 

SINKC2E 

MESSAGE 

LINK 

1 

FO 

BTRY  FDC 

CALL  FOR  FIRE 

VHF  RADIO 

2 

FO 

BN  FSCC 

CALL  FOR  FIRE 

VHF  RADIO 

3 

BTRY  FDC 

HOWITZERS 

FIRE  CMD 

WIRE 

4 

BTRY  FDC 

FO 

MSG  TO  OBS 

VHF  RADIO 

5 
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BTRY  FDC 

SHOT 
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6 
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FO 
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TABLE  8 
SUMMARY  OF  NETWORK  DESIGN  PROCESS 

STEP  1 :  Establish  the  operational  requirement. 

a.  Establish  the  command  and  control  requirement. 

(1)  Identify  C2Es  by: 

(a)  Name 

(b)  Tasks 

(c)  Location  within  the  command  and  control  structure 

(2)  Draw  C2FDs  by: 

(a)  Determining  the  sequence  of  activity  for  the 
mision  area 

(b)  Classifying  the  Information  passed  from  C2E 
to  C2E  in  general  terms 

b.  Establish  the  general  communication  requirement. 
STEP  2:            Construct  an  MEO 

a.  Produce  a  message  by: 

(1)  Decomposing  the  C2E  task  into  elemental  C2E  tasks 

(2)  Correlating  the  elemental  C2E  task  with  required 
Information  elements 

(3)  Correlating  the  Information  elements  with  appropriate 
data  elements 

b.  Identify  connectivity  from  C2E  pairs. 

c.  Produce  a  C2E  link  by: 

(1)  Deriving  the  link  interface  requirements  from  the 
communications  requirements 

(2)  Decomposing  the  link  interface  requirements  Into 
technical  specifications 

STEP  3:  Design  the  Network. 

a.  Specify  the  MEOs  that  comprise  a  C2E  interface 

b.  Select  equipment  to  Implement  the  C2E  links 
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V.  SYSTEM  EFFECTIVENESS  ANALYSIS 

A.  INTRODUCTION 

The  MCES,  as  described  in  Chapter  II,  provides  a  logical  and  orderly  framework 
for  problem  formulation,  system  bounding  and  specification  of  measures.  The  Marine 
Corps'  Technical  Interface  Concepts  (Chapter  IV)  characterizes  the  system  and 
functions,  and  integrates  them.  Assigning  the  generic  Communications  measures 
(Chapter  III)  quantitative  or  qualitative  values  completes  the  first  six  modules  of  the 
MCES.  What  remains  is  to  aggregate  parameters  and/or  measures  and  then  compare 
them  to  some  desired  state.  System  Effectiveness  Analysis  (SEA)  focuses  on  the 
quantitative  aspects  of  obtaining  and  evaluating  measures.  The  steps  of  SEA  can 
therefore  be  embedded  in  MCES,  specifically  in  the  last  modules  (Generation  and 
aggregation).  The  following  is  a  brief  history  of  SEA  provided  the  author  by  Dr. 
Alexander  H.  Levis,  Senior  Research  Scientist,  Massachusetts  Institute  of  Technology. 

B.  BACKGROUND 

System  Effectiveness  Analysis  was  first  tested,  starting  in  1977,  with  funding  from 
the  Department  of  Energy  (DOE)  at  Massachusetts  Institute  of  Technology  (VI IT). 
The  three  year  project  focused  on  large  power  systems  culminating  in  a  final  report 
(Pierre  Dersin)  during  May  1980.  Thesis  works  conducted  primarily  on  command  and 
control  systems  include:  Bouthonnier  (August  1982),  Cothier  (August  1984),  Karam 
(January  1985),  Bohner  (May  1986),  and  Martin  (August  1986).  Other  applications  of 
the  methodology  include  work  on  Flexible  Manufacturing  Systems  (Washington  - 
January  1985)  and  Assessment  of  Internal  Combustion  Engines  (Levis,  Haupt  and 
Andreadakis  -  1985). 

C.  SYSTEM  EFFECTIVENESS  ANALYSIS 

The  description  of  SEA  provided  herein  follows  closely  the  work  of  Cothier 
[Ref.  14:  pp.  11-17]  and  Levis  [Ref.  15:  pp.  2-11,  15-17]. 

The  basic  premise  of  the  methodology  is  that  a  C  system  provides  a  service  to 
the  commander  and  his  forces  and,  conversely,  the  commander  establishes  performance 
requirements  for  the  system.  Or,  the  CJ  system  possesses  a  range  of  performance 
characteristics  and  the  commander  specific  requirements  based  on  his  assigned  mission. 
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The  analysis  assumes  an  ability  to  model  both  system  capabilities  and  commander's 
requirements  in  terms  having  the  same  measure.  This  assumption  is  critical  for  without 
like  dimensions,  the  evaluation  falls  apart. 
1.  Concepts 

The  integration  of  MCES  and  SEA  is  possible  because  both  approaches  are 
based  on  the  same  concepts.  Specifically:  system,  environment,  context,  design 
parameters,  measures  of  performance,  and  measures  of  effectiveness.  Of  these  six  only 
the  term  context  has  not  been  previously  addressed  (see  Chapter  II).  The  system  and 
environment  are  defined  within  a  particular  context  upon  which  the  system  cannot  act, 
but  which  affects  the  system.  It  describes  the  circumstances  surrounding  an  event  or 
situation.  Figure  5.1  shows  the  relation.  Figure  2.3  portrays  the  connection,  derived 
for  this  specific  application. 


ENVIRONMENT 


CONTEXT 


Figure  5.1     System,  Environment,  and  Context. 

2.  Methodology 

The  mission,  system,  environment,  and  context  have  been  defined  in  Modules 
1  through  4  of  MCES,  and  the  Measures  of  Performance  for  a  communication  system 
described  in  Chapter  III.  The  first  step  in  SEA  is  to  select  the  design  parameters  that 
influence  each  system  MOP  (also  characterized  in  Chapter  III).  By  definition,  these 
parameters  are  considered  mutually  independent,  since  they  constitute  the  "independent 
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variables"  in  the  analytical  formulation  of  the  methodology  [Ref.  15:  p.  6].  The  key 
word  or  element  in  step-one  is  system. 

The  second  step  consists  of  defining  parameters  for  mission  requirements.  The 
important  words  being  mission  and  requirement.  Levis  indicates  that  this  step,  while 
implied  in  the  feedback  loop,  is  not  explicit  in  MCES  [Ref.  15:  p.  7]. 

In  steps  three  and  four  the  chosen  system  and  mission  parameters  are  used  to 
define  MOPs  and  Requirements  respectively.  Each  are  expressed  as  functions  of  their 
parameters,  i.e., 

MOP^Ap  =  fi(x1....xk)  (eqn5.1) 

where  x-  are  the  system  parameters,  A-  are  Attributes  or  MOP's;  and, 

Rm  =  W^l--^  (eqn5.2) 

where  y-{  are  the  mission  parameters  and  Rm  are  mission  requirements.  The  issue  of 
independence,  previously  addressed,  is  also  applicable  for  the  A's  and  R's  derived  from 
the  formulation.  Yet  as  dependent  variables,  they  may  be  interrelated  through  use  of 
common  parameters.  Hence,  trade-offs  in  one  area  may  impact  others.  The  results  of 
these  steps  are  specification  of  value(s)  for  both  MOP  and  mission  reflected  as  points 
or  regions  in  their  respective  spaces. 

While  both  spaces  may  be  of  the  same  dimension,  they  could  be  defined  in 
terms  of  different  quantities  or  quantities  scaled  differently.  Step  five  consists  of 
transforming  the  dimensions  into  like  quantities  to  be  defined  on  a  common  coordinate 
frame. 

The  system  measures  of  performance  are  functions  of  system  parameters.  As 
the  x's  in  equation  (1)  van"  over  their  allowable  range,  so  also  do  the  MOPs  generating 
a  locus  in  the  MOP  space.  The  transformation  from  parameter  to  system  locus  is 
illustrated  in  Figure  5.2.  Analagously,  a  set  of  values  that  satisfy  mission  requirements 
are  mapped  to  form  a  mission  locus  (Figure  5.3). 

The  seventh  step  is  the  key  in  analyzing  effectiveness.  In  this  step  the  system 
MOPs  and  mission  Requirements  are  quantitatively  compared  through  the  geometric 
properties  of  the  intersection  of  the  two  loci  (step  6).  These  relations  may  take  on 
either  of  two  forms: 
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Figure  5.2     System  Locus. 

(1)      The  two  loci  do  not  have  any  points  in  common,  i.e.,  the  intersection  of  L, 
and  Lm  is  null: 


L,  n  Lm  =  o 


(eqn  5.3) 


In  this  case,  the  system  does  not  satisfy  the  mission's  requirements,  and  one  would 

define  the  effectiveness  to  be  zero,  regardless  of  which  specific  measure  is  used  (Figure 

5.4). 

(2)      The  two  loci  have  points  in  common,  but  neither  locus  is  included  in  the 
other: 
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Figure  5.3     Mission  Locus. 


(cqn  5.4 1 


with 


Ls  n    Lm  <   Ls  and  Lm 


(eqn 


s  5' 


In  this  case,  a  subset  of  the  values  that  the  MOPs  may  take  satisfies  the  mission 
requirements  (Figure  5.5). 
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Figure  5.4     Form  One. 


Figure  5.5     Form  Two. 

Many  different  measures  can  be  used  to  describe  the  extent  to  which  the  system  meets 
the  requirements.  Each  of  these  measures  may  be  considered  an  MOF.  For  example, 
let  T  be  such  a  measure.    Then  an  eflcctiveness  measure  can  be  defined  bv 
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E,  =  T(LS  n   Lm).T(Ls) 


(eqn  5.6) 


which  emphasizes  how  well  the  system  capabilities  arc  used  in  the  mission,  while 


E2  =  T(LS  n   Lm)/T(Lm) 


(eqn  5.7) 


expresses  the  degree  of  coverage  of  the  requirements  by  the  system  capabilities.    Two 
special  cases  of  the  intersection  include: 


Ls        Sn       Lm 


(eqn  5.8) 


In  this  case,  it  follows  from  Equation  5.8  that  Ls  is  larger  than  Lm  and.  consequently, 
the  ratio  defined  by  Equation  5.6  will  be  less  than  unity.  'I  his  result  can  be  interpreted 
in  two  ways,  first,  only  certain  system  attribute  values  meet  the  requirements  of  the 
mission.  The  second  interpretation  is  that  the  use  of  this  system  for  the  given  mission 
represents  an  inefficient  use  of  resources  since  the  system  capabilities  exceed  the 
mission  requirements.  Inefficiency,  in  turn,  implies  lower  effectiveness  (figure  5.6). 
Alternatively, 


figure  5.6     Form  Two,  Case  A. 
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Ls   n    Lm  =   Ls 


cqn  5.9) 


The  system  locus  is  entirely  contained  in  the  mission  locus  which  might  imply  that  the 
system  completely  satisfies  the  mission  requirements.  However,  there  are  ranges  of 
mission  requirements  not  satisfied  by  the  system  (Figure  5.7). 
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Figure  5.7     Form  Two,  Case  B. 

The  measures  of  effectiveness  given  by  Equation  5.6  or  Equation  5.7  are 
partial  measures.  Let  these  partial  measures  be  denoted  by  {E..}.  To  combine  these 
into  a  single  global  measure,  utility  theory  may  be  used.  Therefore,  the  subjective 
judgements  of  the  system  designers  and  the  users  can  be  incorporated  directly  into  the 
methodology  in  two  ways:  (1)  by  choosing  different  partial  measures,  and  (2)  by 
selecting  a  utility  function.    The  global  effectiveness  measure  is  obtained,  finally,  from 


E  =  u(Ej.  Et E^). 


;eqn  5.10) 


This  is  the  last  step  of  the  SEA  methodology  and  corresponds  to  the  seventh  module  of 
the  MCES. 
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D.       COMMENTS 

A  graphic  representation  of  the  System  Effectiveness  Analysis  methodology  is 
shown  in  Figure  5.8.  This  presentation  implies,  as  has  been  stated,  that  Mission  and 
system  parameters  are  derived  independently.  This  aspect  of  SEA  and  MCES 
procedures  is  in  keeping  with  the  Office  of  Management  and  Budget  (OMB) 
requirement  to  express  requirements  in  mission  terms  [Ref.  5].  This  represents  a  goal 
to  which  all  acquisition  managers  should  subscribe.  Through  successive  iterations  of 
each  process  both  parameters  are  adjusted  to  construct  an  efficient; effective  structure. 
The  mission  requirements  will  normally  represent  a  'first-cut'  or  goal  for  the  system. 
The  system  attributes  describe  contractor  or  other  technical  capabilities  to  meet  the 
mission  requirements.  Examination  of  the  differences  allows  for  redefining  goals  or 
'forcing'  technological  progress.  Broad  disparities  may  also  cause  project  termination 
before  additional  resources  are  spent  on  an  imprudent  venture. 

This  presentation  of  SEA  may  suggest  the  necessity  to  quantify  and  describe 
measures  in  two  or  three  dimensions.  In  fact  SEA  has  worked  command  and  control 
problems  in  up  to  seven  spaces.  In  such  cases,  two  and  three  dimensional  decision  aids 
are  prepared  after  careful  consideration  of  the  processes  involved  in  working  each 
measure.  Limiting  or  forcing  the  use  of  only  two  or  three  measures  in  the  evaluation 
causes  a  loss  of  information  and  may  adversely  affect  the  decision  process. 

Finally,  it  seems  apparent  to  this  author  that  of  all  the  modules  of  MCES  the 
quantitative  aspects  of  module  seven  needs  additional  effort.  Detailed  mathematical 
descriptions,  beyond  the  scope  of  this  thesis,  are  required  to  relate,  generically,  the 
communications  processes  inferred  in  Chapter  III  (Measures).  System  Effectiveness 
Analysis  provides  the  logical  framework  for  expansion  in  this  area. 
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VI.  EXAMPLE  APPLICATION 

A.  INTRODUCTION 

This  chapter  serves  to  demonstrate  application  of  the  tools  previously  described 
in  the  acquisition  process.  The  problem  addressed  is  purposely  simple  allowing, 
especially  in  the  aggregation  module,  a  graphic  portrayal  of  the  analysis  process. 
Analysis  of  a  more  complex  system  would  be  much  more  involved  requiring  a  detailed 
understanding  of  engineering,  mathematics,  and  decision  theory,  beyond  the  scope  of 
this  thesis. 

B.  DESCRIPTION 

An  architectural  evaluation  of  a  large  command  and  control  system  has  been 
conducted  to  assess  the  system  effectiveness  in  light  of  a  recently  conducted  Mission 
Area  Analysis  (MAA).  The  outcome  of  the  study  indicated  that  the  communications 
element  of  the  architecture  was  vulnerable  to  current  and  projected  enemy  electronic 
warfare  (EW)  platforms.  The  following  sub-sections  outline  the  steps  taken  to 
formulate  alternatives  for  the  decision  making  process  using  the  tools  discussed  in 
Chapters  II-V.  Database  considerations  are  separately  noted  at  the  end  of  each  sub- 
section. 

1.  Problem  Formulation 

A  requirement  exists  within  the  C  system  to  transmit  data  among  units.  This 
process  is  interrupted  when  an  enemy  jammer  disturbs  the  link. 

Intelligence  sources  indicate  an  enemy  jamming  presence  capable  of  emitting 
both  UHF  and  SHF  broadband  noise.  The  UHF  emitter  uses  a  5db  gain  crossed 
dipole  antenna  and  the  SHF,  a  42db  dish  antenna.  Both  transmitters  can  generate  up 
to  1000  Watts  of  output  power.  The  jammer  operates  from  an  airborne  platform; 
however,  because  of  friendly  air  suppression,  can  approach  ground  based  sites  no 
closer  than  200  miles.  This  estimate  represents  projected  capabilities  spanning  the  next 
ten  years. 

Database  considerations:   None  specific  to  this  module. 

2.  C~  System  Bounding 

The  physical  entities  of  the  system  are  described  as  Units  Alpha  and  Bravo. 
These  two  command  and  control  elements  (C  Es)  are  first  verified  to  be  elements  in 
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the  data  base  and  then  used  to  ascertain  structure  (organization  hierarchy  and 
information  flow  patterns).  While  Unit  Alpha  is  found  to  be  hierarchically  senior  to 
Bravo,  the  information  flow  patterns  indicate  two-way,  proportional  dialogues;  hence,  a 
requirement  for  full-duplex  communication.  The  bounding  process  also  highlights 
digital  vice  analog  transmission  at  a  data  rate  of  1200  bps  for  the  current  terminal 
devices  and  2400  bps  upgrades  during  the  next  decade.  Units  Alpha  and  Bravo  operate 
no  closer  than  200  and  no  further  than  S00  miles  apart.  The  physical  depiction  of  the 
bounding  process  is  shown  in  Figure  6.1. 

Database  considerations:  If  a  OE  is  not  found  in  the  database,  then 
justification  for  inclusion  is  compiled  and  submitted  to  the  database  manager  for 
action. 


Figure  6.1     Bounded  System. 

3.  C    Process  Definition 

The    OEs   and    the    most    basic    link   requirements   were    described   in    the 

'bounding'  module.     Following  the   MCES  and   Marine  Corps  descriptive  processes, 

outlined  in  Chapters  II  and  IV,  it  is  now  necessary  to  derive  the  message  standards  (or 

C     process   function)  prior  to   system   integration.    This   section   borrows   from  the 

architectural  process   definition  conducted   (assumed)  prior  to   this   communications 

system  study.    During  the  previous  evaluation,  the  environmental  'initiator'  of  the  C 

~) 
process,  the  internal  C^  mechanisms,  and  the  desired  outputs  were  manipulated  and 

"> 
appraised  over  varying  scenarios  or  contexts.    C"E  tasks  and  information  requirements 

are  generated  and  used  to  specify  the  message  standard(s).   Tasks  are  decomposed  into 

subtasks.    The  subtasks  specify  message  elements  which  are  described  in  the  Message 

Elements     Dictionary'     (MED)     as     Data     Field     Identifiers;  Data     Unit     Identifiers 
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(DFI  DUIs).   This  functional  decomposition  describes,  alphanumerically,  the  command 
and  control  process  of  interest. 

Database  considerations:  Specific  DFIDLTs  are  assumed  to  exist  in  the 
database.  If  the  database  is  missing  these  identifiers,  justification  is  provided  to  have 
them  included. 

4.  Integration 

The  bounded  system  (OEs  and  links)  coupled  with  required  processes 
(messages)  forms  Message  Exchange  Occurrences  (MEOs).  These  MEOs  are  analyzed 
and  used  to  depict  the  overall  requirement  in  the  form  of  a  command  and  control  flow 
diagram  (C  FD)( Figure  6.2).  The  MEO  (or  set  of  MEOs)  is  then  compared  with 
existing  standards  using  the  interoperability  database.  For  purposes  of  this 
explanation,  the  C  Es  and  message  standard  elements  exist  as  specified  in  the  MEOs. 
The  link  standards,  while  similar,  will  vary  as  a  result  of  friendly  and  threat 
technological  change.  The  database  (MEOs)  will  be  used,  however,  for  initial  system 
evaluation.  This  process  allows  analysis  of  existing  systems  prior  to  specification  of 
new  hardware  or  software  requirements,  thus  verifying  that  changes  are  necessary  to 
meet  the  mission  objectives  specified  in  Module  1. 

Database  considerations:  Assuming,  as  in  this  case,  that  the  C  Es  and 
DFI/DLTs  exist  in  the  database,  and  that  link  standards  exist  for  the  system  under 
consideration,  once  a  new  communications  system  is  developed,  a  means  must  exist  for 
differentiating  between  the  former  and  current  MEOs.  As  long  as  the  older  links  are  in 
use,  a  distinction  is  necessary  for  the  new  parameters. 

5.  Measures  of  Performance 

While  all  of  the  generic  measures  described  in  Chapter  III  may  be  applicable, 
this  analysis  will  focus  on  speed,  survivability,  and  flexibility. 

Database  considerations:  The  database  may  contain  information  pertaining  to 
previous  evaluations.  This  information  should  include  any  measures  used  in 
conducting  the  study. 

6.  Data  Generation 

The  performance  of  the  communications  system  must  be  ascertained  using  (a) 
data  generation  technique(s)  (see  database  considerations).  The  system  itself  must 
meet  the  following  requirements: 

•  speed:  1200  to  4S00  bps 

•  survivability:  10"3  to  LOT7  BER 

•  flexibility:  ability  to  operate  varying  bit  rates  over  the  required  range 
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Figure  6.2     Integration  Depiction. 

The  speed  requirement  meets  both  current  and  anticipated  ( 1 200-2400bps)  terminal 
capabilities.  The  additional  2400bps  allows  engineers  flexibility  in  design,  yet  caps 
available  speed  avoiding  spending  for  unnecessary  capacity.  The  Bit-Error-Rate  (BER) 
specifications  should  meet  current  and  planned  needs  and  also  set  an  upper  limit  on 
expenditures.  The  flexibility  measure  is  subjective.  It  is  included  for  the  decision 
maker  to  choose  between  identical  or  nearly  identical  systems  proposals. 

Database  considerations:   This  data  is  based  on  both  subjective  judgement  and 
specifications  available  for  the  current  system  (found  in  the  1DB). 
7.  Aggregation  of  Measures 

The  final  module  addresses  synthesis  of  the  mission  requirements  and  then 
compares  existing  and  proposed  systems  with  these  baseline  (mission)  needs.  The 
aggregation  process  will  use  the  descriptive  tools  of  Systems  Effectiveness  Analysis 
(SEA)(Chapter  V)  to  ensure  requirements  are  met. 

Database  considerations:  The  final  check  on  whether  the  system  meets 
mission  requirements  is  conducted  by  verifying  the  completion  of  all  MEO  tasks  and 
subtasks. 
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C.       ANALYSIS 

As  stated  in  the  thesis  introduction,  this  section  assumes  knowledge  of 
communications  engineering  principles.  The  following  additional  assumptions  apply  to 
the  system  analysis: 

1)  Operating  distances  and  jammer  standoff  will  remain  the  same  over  the  project 
life-cycle. 

2)  The  jammer  will  always  be  able  to  work  within  the  footprint  of  the  satellite 
antenna  and  outside  the  range  of  friendly  air-suppression  systems. 

The  system  currently  in  use  will  help  determine  a  baseline  for  the  analysis.  An 
AN/TSC-1  is  used  at  Unit  Alpha  and  an  AN/GRC-1  at  Unit  Bravo.  Tables  9  and  10 
outline  their  respective  specifications.  The  system  uses  a  geostationary  full  processing 
satellite  as  a  relay  platform  described  in  Figure  6.3  and  Table  1 1. 


TABLE  9 

TSC-1  SPECIFICATIONS 

(Tactical  Satellite  Communication^ 

Frequency: 
Antenna: 

Transmitter: 
Power  Amplifier: 

SHF  (7.5-8.5  Ghz) 
10  meter  parabola 
Sidelobes,  -30  db 

8000  Watts 

Receiver: 
G/T 

14  db 

Modulation: 
Spread  Spectrum 
PSK 
Data  Rates 

(5  Mhz  chip  rate) 

75,150,300,600 
1200  or  2400  bps 

Figure  6.4  highlights  the  current  performance  based  on  the  specifications 
previously  addressed.  As  evidenced  by  the  performance  line,  outside  the  bounds  (data 
generation)    of  the   desired    requirements,    the    existing    system   does    not    meet    the 
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TABLE 

10 

GRC-1  : 

SPECIFICATIONS 

(Ground  Radio  Communications! 

Frequency 

UHF  (225-400  Mhz) 

Antenna 

Inverted  Discone 
Gain  =  9db 

Transmitter: 

Power  Amplifier 

100  Watts 

Receiver: 

Noise  Figure 

6db 

Modulation: 

Frequency  hop 

HopBt  =  175  Mhz 

PSK 

Data  Rates 

75,150,300,600, 
1200  or  2400  bps 

Figure  6.3     Satellite  Block  Diagram. 
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TABLE  11 

SATELLITE  TECHNICAL  PARAMETERS 

Uplink 

SHF 

UHF 

Antenna: 

Horn  (Gain  =  29  db) 

Crossed  dipole  (Gain  -  4  db) 

G/T: 

Odb 

-26  db 

Channel  Carrier 

8Gnz 

Hopped 

Receiver  Bandwidth 

10  Mhz  (Spread) 

Hopped  (225-400  Mhz) 

Downlink 

SHF 

gHF 

Antenna: 

Horn  (Gain  =  29  db) 

Helix  (Gain  =  9  db) 

Power: 

TWTA  (40  Watt) 

Solid  State  (200  Watt) 

Channel  Carrier 

8.3  Ghz 

Hopped 

Transmit  Bandwidth 

10  Mhz  (Spread) 

Hopped  (225-400  Mhz) 

Modulation 

PSK 

PSK 

standards.  It  now  remains  to  further  refine  the  mission  performance  space  in  order  to 
assure  that  request  for  proposal  (RFP)  specifications  give  designers  an  accurate 
description  of  requirements  and  channelize  their  efforts  in  keeping  with  budgetary 
limits  and  mission  requirements.  The  mission  requirements  relate  performance  as  a 
function  of  data  rate  and  bit-error-rates.  The  budget  limits  are  constructed  given  cost- 
performance  data. 

Figure  6.5  illustrates  a  hypothetical  cost-performance  curve  for  this 
communications  system.  While  any  number  of  curves  may  be  realistic  in  this 
application,  lacking  actual  data,  this  curve  represents  the  author's  opinion  that  as 
performance  improves,  cost  increases  at  an  increasing  rate.  Inasmuch  as  future 
terminal  applications  will  push  the  communications  system  past  current  technology, 
research  and  development  costs  will  increase.  By  keeping  cost  performance  in  line  with 
budget  constraints,  an  upper  limit  in  the  mission  space  can  be  generated.  Such  a  limit, 
when  applied  to  Figure  6.4  may  look  as  projected  in  Figure  6.6.  The  line  indicates  that 
as  performance  increases  it  will  cost  more  for  the  system.  At  lower  speeds  (1200bps) 
adding  funds  will  produce  more  significant  gains  in  bit-error-rate;  whereas,  at  higher 
speeds  (4800bps)  a  similar  addition  of  funds  nets  less  improvement  in  BER. 
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Figure  6.4     System  Performance. 
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Figure  6.5     Cost-Performance  Curve. 
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Figure  6.6     System  Performance  with  Cost  Line. 

Systems  planners  and  engineers  have  indicated  that  current  terminal  equipment 
requires  a  10"5  BLR  @  1200bps  and  no  worse  than  10"3  BLR  @4S00bps  to  sustain 
desired  thruput  in  current  and  future  applications.  While  thruput  is  used  as  a  measure 
in  both  mission  and  cost  line  determinations,  the  mathematical  formulation  of  inputs 
will  vary.  Hence,  the  BLR  line  (mission)  will  not  be  parallel  to  the  cost  line  previously 
addressed.  Both  limits  assume  a  linear  relationship  that  may  or  may  not  exist.  The 
BLR  limits  line  is  shown  in  Figure  6.7.  This  line  indicates  the  minimum  acceptable 
performance  to  meet  mission  requirements. 

A  realistic  estimate  of  the  mission  space  based  on  speed  and  survivability  is 
compiled  in  Figure  6.8  by  combining  Figures  6.4  through  6.7.  This  picture  gives  the 
designer  a  more  definitive,  measure  oriented  description  of  the  desired  system.  It  also 
focuses  the  analysis  and  decision  process,  in  that  alternative  systems  outside  the  shaded 
area  'C  are  either  too  expensive  (area  B)  or  unacceptable  given  the  threat  and 
terminal  requirements  (area  'A').  Figure  6.8  highlights  the  fact  that  the  original 
(bordered  square)  requirements  space  (10"J  to  10"'  BER  and  1200  to  4800bps)  allowed 
too  much  leeway  in  the  system  design  process. 
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Figure  6.7     System  Performance  with  BliR  Limits. 
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Figure  6.8     Mission  Performance  Space. 
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D.       SUMMARY 

This  chapter  has  demonstrated,  through  analysis  of  a  simple  project,  use  of  the 
tools  previously  explained  in  this  thesis.  Several  comments  relative  to  the  analysis  are 
in  order. 

The  communications  system  of  interest  was  made  purposely  simple  to 
demonstrate  flow  between  the  modules  of  MCES  and  to  highlight  the  supplementary 
tools  from  which  the  modules  are  filled.  A  detailed  explanation  of  cost-performance 
analysis  is  beyond  the  scope  of  this  thesis,  hence  the  cursory  examination  in  Section  C. 

Another  area  intentionally  omitted  is  a  detailed  examination  of  the  measures 
chosen  for  this  application.  Again,  the  measures  chosen  are  used  to  demonstrate  the 
methodology,  not  to  define  hard-and-fast  guidelines  for  analysis  of  like  systems.  As 
previously  explained,  many  measures  could  have  been  included  in  the  analysis.  This 
would  have  required  a  detailed  study  of  not  only  the  source  of  data,  but  also  the 
mathematical  manipulations  necessary  to  present  the  information  in  understandable 
form.  As  mentioned  in  Chapter  V,  the  modelling  of  parameters  to  create  or  support 
measures  of  performance  or  effectiveness  is  perhaps  the  hardest  concept  in  this 
collection  of  tools  to  deduce  or  to  comprehend. 

Finally,  the  decision  process  has  been  omitted.  The  intent  of  this  work  is  to 
explain  and  provide  an  easily  understandable  framework  within  which  acquisition 
projects  can  be  evaluated  short  of  an  actual  decision.  The  decision  process  is  multi 
faceted,  as  highlighted  in  Chapter  II.  The  information  provided  in  Figure  6.8  will  be 
useful  in  framing  this  effort. 

The  project  manager  or  decision  authority  has  refined  the  original  data  generated 
in  Module  6  to  the  point  where  a  viable  mission  space  has  been  created.  Alternative 
communications  systems  that  fit  or  more  closely  fit  the  space  may  provide  a  logical 
choice  for  contract  award.  As  an  example,  if  the  receive  antenna  gain  (Gr)  were 
adjusted  to  10  or  lldb,  new  system  curves,  relative  to  the  mission  space,  can  be  created 
(Figure  6.9).  Such  an  adjustment  may  provide  additional  direction  to  engineers  or 
validate  the  alternative  system's  claim  to  requirements  satisfaction. 

It  is  not  certain  from  the  information  provided  what  percentage  of  compliance 
with  the  mission  requirements  is  met  by  any  of  the  alternative  systems.  The 
intersection  of  the  'system  performance  line'  with  the  mission  space  is  in  actuality  a 
collection  of  points,  which,  mathematically,  cannot  be  assigned  a  percentage 
compliance.  This  highlights  a  potential  problem  with  presentation  of  requirements  in 
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cither  two  or  three-dimensional  space.  While  the  picture  gives  a  more  accurate 
description  of  desired  ranges,  it  should  not,  at  least  in  this  application,  be  used  to  fully 
evaluate  the  project.  The  implication  here  is  that  if  the  system  line  falls  in  hand  "C", 
then  it  meets  the  stated  requirements  and  must  be  selected.  Since  none  of  the  systems 
fall  completely  within  the  band,  presumably  no  selection  can  be  made.  Had  the 
evaluation  been  conducted  using  additional  measures,  the  possibility  of  answering  the 
mission  requirements  may  have  been  enhanced  insofar  as  the  pictorial  presentation  is 
concerned.  Ultimately,  if  the  constraints,  as  functions  of  other  parameters,  are  allowed 
to  vary,  a  more  dynamic  decision  process  is  created.  Stated  otherwise,  by  adding  more 
dimensions  (measures),  the  possibility  of  compliance  with  requirements  or  tradeoffs 
within  the  mission  bounds  is  improved.  The  project  manager  must  define  the 
judgement  criteria,  in  percentages  or  otherwise,  as  part  of  the  decision  process  and 
provide  this  criteria  in  the  request  for  proposal  (RIT).  specifically  in  the  statement  of 
work  (SOW). 
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Figure  6.9     Alternative  Communication  Systems. 
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VII.  CONCLUSIONS/RECOiMMENDATIONS 

A.  SUMMARY 

This  thesis  has  described  and  explained  the  use  of  four  tools  recommended  for 
project  managers  when  procuring  communications  systems.  The  Modular  Command 
and  Control  Evaluation  Structure  (VICES)  provides  the  framework  for  this  approach. 
It  is  used  initially  at  the  architectural  level  to  evaluate  the  command  and  control 
system  of  interest.  Depending  on  the  application,  this  process  may  start  globally  at  the 
National  Command  Authority  (NCA)  level,  working  successively  through  the 
command  hierarchy  to  a  particular  C"  system.  At  the  C  system  level, 
communications,  weapons  systems,  intelligence  sources,  displays,  and  computer  devices 
are  evaluated  as  to  their  contribution  to  the  effectiveness  of  the  C    system. 

Three  tools  have  been  discussed  as  means  by  which  the  modules  of  MCES  are 
implemented.  Generic  measures  of  performance/effectiveness  for  the  communications 
system  have  been  described.  Marine  Corps  Technical  Interface  Concepts  have  been 
used  to  bound  the  problem,  define  the  C  process  required  of  the  bounded  structure 
and  then  integrate  the  system  elements  and  functions.  The  Marine  Corps 
interoperability  database  (IDB)  is  proposed  as  a  source  for  data  to  quantitatively 
describe  the  generic  measures  specified  for  the  system.  The  third  tool,  System 
Effectiveness  Analysis  (SEA),  serves  to  assist  in  the  data  generation  process  and  to 
analyze  and  refine  (aggregate)  the  chosen  measures  bounded  by  mission  needs  and 
budgetary  constraints.   All  of  these  means  serve  as  aids  in  the  decision  process. 

B.  CONCLUSIONS 

Use  of  a  structured  approach  in  the  evaluation  and  acquisition  processes  helps 
ensure  that  all  dimensions  of  the  problem  are  considered,  common  terms,  definitions, 
and  procedures  help  managers  understand  the  process  they  are  directing  and  assists 
decision  makers  by  presenting  facts  and  alternatives  in  a  common  format.  The 
existance  of  databases  of  information  pertaining  to  structure,  processes  and 
specifications  will  help  managers  to  evaluate  existing  systems.  The  manager  can  also 
use  this  common  source  of  data  as  a  baseline  in  exploring  future  applications. 
Continued  application  of  these  tools,  relative  to  the  database,  will  sustain  maintenance 
of  the  information  contained  therein,  helping  to  assure  accurate  future  assessments. 
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C.       RECOMMENDATIONS 

Work  on  this  thesis  has  suggested  to  the  author  five  areas  of  potential  study 
relative  to  the  processes  described. 

First,  concerning  problem  formulation.  Mission  Area  Analysis  (MAA)  is 
presently  used  to  determine  the  need  for  system  evaluation.  An  explanation  of  the 
methodology  of  MAA  would  enhance  the  problem  formulation  module  of  MCES. 

Second,  the  generic  measures  presented  herein  are  the  author's  interpretation  o[ 
significant  performance  requirements  for  a  communications  system.  Review  of  other 
documents  suggests  additional  measures  are  applicable.  For  example,  availability  and 
maintainability  may  be  specific  measures,  rather  than  criteria  dependent  on  reliability. 
An  effort  needs  to  be  made  to  refine  the  measure  selection  process.  As  has  been 
suggested  in  this  thesis,  the  parameters  used  to  discern  measures  of 
performance  effectiveness  may  be  the  same;  however,  formulation  of  the  specific 
criterion  is  different  allowing  measure  independence.  The  interoperability  database 
suggest  one  means  wherein  this  issue  of  independence  can  be  evaluated. 

Third,  this  thesis  has  suggested  use  of  the  interoperability  database  as  a  means 
whereby  baseline  systems  can  be  defined  for  the  analysis  process.  Modeling  of  the 
system  with  all  of  its  elements  (people,  processes,  and  equipment)  has  been  suggested 
but  not  described. 

Fourth,  it  has  been  submitted  that  the  collection  of  tools  illustrated  herein  serve 
as  an  aid  to  decision  makers:  however,  little  has  been  written  on  the  subject  of  the 
decision  process.  An  understanding  of  the  means  and  psychology  of  decision  making 
is  critical  to  presentation  of  viable  alternatives  that  support  mission  need. 

Finally,  a  simple  example  has  been  used  to  demonstrate  the  utility  of  a  collection 
of  tools  in  standardizing  the  acquisition  and  evaluation  processes.  Successive 
applications  with  existing  and  proposed  architectures  will  ultimately  validate  the 
usefulness  of  this  framework. 
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APPENDIX  A 
DICTIONARY  OF  ACRONYMS  AND  TERMS 

Bit-Error-Rate 

Bits-Per-Second 

Command  and  Control 

Command  and  Control  Element 

Command  and  Control  Flow  Diagram 
C  Command,  Control  and  Communications 

C  I  Command,  Control,  Communications  and  Intelligence 

C  SCSC  Cost.  Schedule  Control  Systems  Criteria 

CBR  Chemical,  Biological,  and  Radiological 

CDR  Critical  Design  Review 

CI  Configuration  Item 

COC  Combat  Operations  Center 

COMSEC  Communications  Security 

D,V  Demonstration,  Validation 

DFD  Data  Flow  Diagram 

DFI  Data  Field  Identifiers 

DoD  Department  of  Defense 

DOE  Department  of  Energy 

DSAM  Direct  Support  Artillery  Mission 

DSARC  Defense  System  Acquisition  Review  Council 

DTC  Design  to  Cost 

DUI  Data  Unit  Identifiers 

ECCM  Electronic  Counter  Counter  Measures 

EMP  Electromagnetic  Pulse 

EW  Electronic  Warfare 

FCA  Functional  Configuration  Audit 

FO  Forward  Observer 

FSCC  Fire  Support  Coordination  Center 

FSD  Full  Scale  Development 

GOS  Grade-of-Service 

IDB  Interoperability  Database 
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IMP 

IOC 

IPS 

JCS 

JINTACCS 

JMSNS 

JRMB 

JTC3A 

LAAM  BN 

LCC 

LPE 

LPI 

MAA 

MAGTF 

MCES 

MEO 

MIT 

MNS 

MOD 

MOE 

MOFE 

MOP 

MOPE 

MORS 

MTACCS 

MTBF 

MTS 

MTTR 

NASA 

OFPP 

OJCS 


Interoperability  Management  Plan 

Initial  Operational  Capability 

Integrated  Program  Summary 

Joint  Chiefs  of  Stall 

Joint  Interoperability  of  Tactical 

Command  and  Control  Systems 

Justification  for  Major  Systems  New  Start 

Joint  Requirements  Management  Board 

Joint  Tactical  Command,  Control,  and 

Communications  Agency 

Light  Anti-Air  Missile  Battalion 

Life  Cycle  Cost 

Low  Probability  of  Exploitation 

Low  Probability  of  Intercept 

Mission  Area  Analysis 

Marine  Air  Ground  Task.  Force 

Modular  Command  and  Control  Evaluation  Structure 

Message  Exchange  Occurrence 

Massachusetts  Institute  of  Technology 

Mission  Need  Statement 

Measure  of  Design 

Measure  of  Effectiveness 

Measure  of  Force  Effectiveness 

Measure  of  Performance 

Measure  of  Policy  Effectiveness 

Military  Operations  Research  Society 

Marine  Corps  Tactical  Command  and 

Control  Systems 

Mean  Time  Before  Failure 

Marine  Tactical  System 

Mean  Time  To  Repair 

National  Aeronautics  and  Space  Administration 

Office  of  Federal  Procurement  Policy 

Office  of  the  Joint  Chiefs  of  Staff 
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OMB 

OPFAC 
p3j 

PCA 

PDM 

PDR 

POM 

PPBS 

PRR 

RDT&E 

RF 

RFP 

SARC 

SCP 

SDDM 

SDR 

SE 

SEA 

SECDEF 

SHF 

SXR 

SOW 

SRR 

TDS 

TIC 

TIDP 

TRI-TAC 

UHF 


Office  of  Management  and  Budget 

Operations  Facility 

Pre-planned  Product  Improvement 

Physical  Configuration  Audit 

Program  Decision  Memorandum 

Preliminary  Design  Review 

Program  Objective  Memorandum 

Planning  Programming  and  Budgeting  System 

Production  Readiness  Review 

Research,  Development,  Test  &  Evaluation 

Radio  Frequency 

Request  for  Proposal 

System  Acquisition  Review  Council 

System  Concept  Paper 

Secretary  of  Defense  Decision  Memorandum 

System  Design  Review 

System  Engineering;  or,  Support  Equipment 

System  Effectiveness  Analysis 

Secretary  of  Defense 

Super  High  Frequency 

Signal-to-Noise  Ratio 

Statement  of  Work 

System  Requirements  Review 

Tactical  Data  System 

Technical  Interface  Concepts 

Technical  Interface  Design  Plans 

The  Joint  Tactical  Communications  Office  that  preceded 

establishment  of  JTC  A. 

Ultra  High  Frequency 
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APPENDIX  B 
ACQUISITION  POLICIES 

1.  INTRODUCTION 

The  process  of  acquiring  new  government  systems  is  complex.  While  no  single 
source  describes  all  of  the  management  principles  involved  in  a  product's  life  cycle,  the 
following  excerpt  from  Reference  16  (pp.  1-1  thru  1-5)  provides  a  good  overview  of  the 
chronology  and  requirements  for  governmental  procurement.  The  processes  remain 
essentially  the  same;  however,  several  structure  changes,  made  since  the  reference  was 
published,  are  worthy  of  note.  The  DSARC  (Defense  System  Acquisition  Review 
Council)  has  been  replaced  by  a  Joint  Resources  Management  Board  (JRMB);  and,  the 
Defense  Acquisition  Executive  (DAE)  is  now  the  USD(A),  Undersecretary  of 
Defense(Acquisition),  a  new  post  created  in  1986. 

2.  APPROACH 

a.  Government  Acquisition  Policies 

Over  the  past  several  decades,  as  large  systems  have  evolved  and  matured,  the 
problems  encountered  in  the  management  of  these  systems  have  caused  the  DoD  to 
develop  a  systematic  engineering  management  process  that  directs  periodic  review  and 
control  of  the  program  throughout  its  acquisition  and  operational  life.  In  the  early 
1970s,  the  Office  of  Federal  Procurement  Policy  (OFPP)  was  established  to  provide 
policies,  methods,  and  criteria  for  the  acquisition  of  property  and  services  for  all 
executive  agencies.  In  1976  the  Office  of  Management  and  Budget  (OMB)  Circular 
A-109  was  published.  The  philosophy  behind  OMB  Circular  A-109  is  for  the 
Government  to  become  a  more  reliable  customer  by  standardizing  its  acquisition 
policies  throughout  the  Government  by  avoiding  major  contract  delays  and 
cancellations,  and  to  promote  an  unbiased  concept  definition.  It  requires  that  the 
Government  operating  agency  establish  and  justify  a  valid  requirement  for  a  capability, 
which  must  be  approved  by  the  executive  agency  head  (Secretary  of  Defense,  NASA 
Administrator,  etc.)  before  involving  industry  in  the  system  acquisition  process.  The 
approval  of  this  needed  capability  also  establishes  the  priority  and  theoretically  the 
availabilitv  of  resources  to  fulfill  the  need. 
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Approval  of,  for  example,  a  DoD  Justification  for  Major  System  New  Start 
(JMSXS)  or  a  NASA  Mission  Need  Statement  (MNS)  initiates  the  acquisition  cycle. 
Circular  A- 109  requires  that  this  need  be  recertified  by  the  agency  head  upon  approval 
of  a  selected  design  concept  for  test  and  demonstration,  again  before  committing  the 
system  to  production.  The  acquisition  process  may  be  terminated  at  any  of  these 
decision  points.   The  DoD  approach  to  be  followed  using  A- 109  includes: 

•  Prototyping  and  early  demonstration  to  reduce  risk 

•  Program   control   and   ritualized   review  by   the   Defense   Svstem  Acquisition 
Review  Council  (DSARC) 

•  Placing  of  emphasis  on  tradeoffs  between  cost,  performance,  schedule,  and  risk. 

In  May  1981,  then  Deputy  Secretary  of  Defense  (SECDEF)  Frank  Carlucci 
proposed  a  number  of  changes  which  became  the  DoD  Acquisition  Improvement 
Program  and  included: 

Revising  DSARC  reviews  to  decentralize  responsibility 

Encouraging  capital  investment  to  enhance  productivity 

Seeking  earlier  IOC  for  less  ambitious  goals,  update  later 

Incentivizing  reliability  and  maintainability 

Structuring  contracts  to  consider  risks  shared  by  Government  and  contractor 

Putting  more  emphasis  on  credibility  rather  than  lowest  bid 

Reducing  cost  and  time  to  procure  small  items  by  raising  thresholds  for  direct 
Program  Office  and  cost  data  reporting 

Reducing  requirements  for  socioeconomic  program  burdens 

Making  more  realistic  cost  estimates  and  higher  front-end  funding 

Permitting  purchases  with  multiyear  contracts 

■i 
Promoting  the  use  of  Pre-Planned  Product  Improvement  (PI). 

As  a  result  of  his  actions  and  the  subsequent  review  and  approval  process, 

eight  decisions  have  been  made  that  directly  affect  the  DSARC  process: 

DSARC  decision  milestones  are  to  be  reduced  to  Requirement  Validation 
(Milestone  I)  and  Program  Go-Ahead  (Milestone  II). 

The  criterion  for  DSARC  review  is  increased  to  S200  million  in  Research, 
Development,  Test,  and  Evaluation  (RDT&E)  and  SI  billion  procurement  in 
FY80  dollars. 

The  DSARC  briefing  and  data  requirements  are  decreased  to  increase  the 
efficiency  of  DSARC  and  other  program  reviews. 

The  appropriate  service  Secretary  or  Chief  in  included  in  the  DSARC 
membership. 

The  Under  Secretarv  of  Defense  for  Research  and  Engineering  (USD RE) 
remains  the  Defense  Acquisition  Executive  (DAE). 
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•  Integration  of  the  DSARC  and  the  Planning  Programming,  and  Budgeting 
Svstem  (PPBS)  process  is  accommodated  bv  requireihg  that  fiscally  executable 
programs  be  presented  for  DSARC  review. 

•  The  J  MSN'S  is  to  be  submitted  with  the  service  Program  Objective 
Memorandum  (POM)  to  initiate  a  new  program.  The  J  MSN'S  defines  the 
mission  need,  identifies  boundarv  conditions,  and  provides  an  initial  acquisition 
strategy  outline. 

In   March    19S2   DoDD    5000.1,   Major   Systems   Acquisition,   was   revised    to 

reflect  the  following  acquisition  management  principles  and  objectives: 

•  Ensure  effective  design  and  price  competition 

•  Improve  system  readiness  and  sustainability 

•  Increase  the  stability  in  acquisition  programs  through  effective  long-range 
planning,  use  of  evolutionary  alternatives  instead  of  solutions  at  the  frontier  of 
technology,  realistic  budgeting  and  funding  of  programs  for  the  total  life  cvcle, 
and  planning  to  achieve  economical  production  rates 

•  Delegate  authority  to  the  lowest  levels  of  the  service  that  can  provide  a 
comprehensive  review  of  the  program 

•  Achieve  a  cost-effective  balance  between  acquisition  costs,  ownership  costs,  and 
system  effectiveness  in  terms  of  the  missions  to  be  performed. 

b.  System  Life  Cycle 

The  life  cycle  for  a  typical  major  DoD  system  acquisition  is  depicted  in  Figure 

A.l,  showing  both  the  previous  and  current  practice.    The  NASA  life  cycle  combines 

the   elements   of  the    DoD   conceptual   and   validation   phases   into   one   phase   and 

envisions  no  production  phase;  operational  and  deployment  phases  are  comparable. 

Regardless  of  nomenclature  the  purpose  is  the  same;  from  establishing  the  need  to 

placing  the  system  into  operation.  System  Engineering  is  an  iterative  process  whereby 

individual  aspects  of  the  program,  such  as  design,  costs,  or  risks,  for  example,  are 

successively  reviewed  at   the   designated  milestones  and   the  need   recertified  before 

additional  resources  are  authorized  by  the  reviewing  authority  for  the  continuation  of 

the  program.    Any  DoD  milestone  decision  will  be  made  by  the  SECDEF  only  after  a 

formal   review   or   audit    of  the   contractor   effort    by   Government    Program   Office 

personnel.    These  reviews,  which  increase  in  depth  of  detail  as  the  system  life  cycle 

progresses,  form  the  basis  for  the  presentations  that  Government  program  managers 

will  use  to  justify  further  development  of  the  program.    It  must  be  emphasized  that  for 

an  actual  program,  the  agency  head  must  decide  either  to  continue  the  present  phase. 

proceed  to  the  next  phase,  or  cancel  the  program.    The  SecDef  can  also  direct  a  DoD 

Program  to  omit  Demonstration  Validation  and  proceed  with  Full  Scale  Development. 

A  similar  cycle  is  required  for  "less  than  major  systems,"  but  with  Service  or  Major 

Command  Milestone  approval  instead  of  DoD. 
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Figure  A.l     Major  DoD  System  Life  Cycle  (Ref.  DoDD  5000.1). 

/.    Concept  Exploration  (CE)  Phase 

Concept  Exploration  (CE)  is  initiated  with  the  approval  of  the  service 
POM,  which  includes  the  JMSNS  by  the  SECDEF,  who  signs  the  Program  Decision 
Memorandum  (PDM).  It  extends  to  the  program  decision  that  authorizes 
accomplishment  of  either  Demonstration/Validation  or  Full  Scale  Development  phases. 
Approval  by  SECDEF  is  contingent  upon  the  DoD  component  having  sufficient 
reserves  to  complete  concept  Exploration.  This  phase  defines  and  selects  system 
concepts   for   further  development.     Most  activity  during   this  phase  is   an  internal 
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Government  responsibility;  however,  several  parallel  short-term  contracts  are  required 
by  OMB  circular  A- 109  to  promote  the  most  cost-effective  solution.  The  output  from 
the  contractor  effort  must  define  performance  envelopes,  identify  risks,  present 
preliminary  alternative  design  concepts,  and  determine  the  production  feasibility  of  the 
design,  with  schedule  estimates  and  a  preliminary  Life  Cycle  Cost  (LCC)  estimate. 
These  will  be  used  by  the  Government  to  establish  a  functional  baseline,  usually  in  the 
form  of  a  Type  A  System  Specification  (Ref.  MIL-STD-490).  The  output  should  also 
contain  a  proposed  Request  for  Proposal  (RFP)  for  the  Demonstration; Validation 
phase.  The  output  from  these  contractor  efforts  is  reviewed  by  Government  program 
management  for  adequacy.  A  System  Requirements  Review  (SRR)  may  be 
accomplished  here  or  very  early  in  the  Demonstration/Validation  phase.  Following 
this.  Government  and  contractor  efforts  are  combined  into  a  System  Concept  Paper 
(SCP)  which  contains  an  updated  needs  statement,  a  description  of  alternatives  with 
performance  estimates,  an  acquisition  strategy,  a  program  structure  management  plan, 
and  a  risk  assessment.  The  SCP  is  the  basis  for  review  and  decision  to  proceed  into 
further  program  phases.  The  SCP  is  reviewed  first  by  the  service  component  System 
Acquisition  Review  Council  (SARC)  and.  if  approved,  the  DSARC.  This  review 
constitutes  Milestone  I. 

The  DSARC  reconfirms  the  need,  determines  that  risks  are  adequately 
considered  and  that  program  structure,  technical  planning,  and  LCCs  have  been 
established.  When  the  SCP  meets  all  objectives, it  is  forwarded  to  the  SECDEF  with 
recommendations  to  proceed  to  the  Demonstration,  Validation  or  Full  Scale 
Development  phase.  Approval  by  SECDEF  is  documented  in  a  SECDEF  Decision 
Memorandum  (SDDM)  and  authorizes  the  service  to  prepare  and  release  an  RFP.  The 
RFP  contains  the  functional  baseline,  management  approach,  and  the  Statement  of 
Work  (SOW)  that  describes  the  scope  of  the  contractor  effort  for  the  approved  phase. 
2.    Demonstration!  Validation  (D/V)  Phase 

The  Demonstration,  Validation  (D/V)  phase  is  initiated  by  the  release  of  an 
RFP  by  the  Government.  After  proposal  evaluation  and  contract  award,  the  System 
Engineering  (SE)  becomes  a  contractor  effort,  usually  by  two  or  more  contractors. 
The  D  V  competitive  environment  may  be  maintained  through  Full  Scale  Development 
(FSD).  The  objective  in  the  Validation  phase  is  to  determine  whether  to  proceed  with 
FSD.  The  output  of  this  phase  should  establish  firm  and  realistic  performance 
specifications  (allocated  baseline)  that  meet  the  operational  and  support  requirements 
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of  the  contract  SOW.  This  allocated  baseline,  which  is  also  described  as  a  design 
requirements  baseline,  incorporates  technological  approaches  proposed  to  satisfy 
requirements  established  by  the  functional  baseline.  As  the  System  Engineering 
process  progresses  from  the  functional  to  the  allocated  baseline,  required  configuration 
Items  (CIs)  are  identified.  The  process  includes  trade  studies  to  ensure  that  the  system 
being  defined  satisfies  the  functional  baseline  and  the  SOW  requirements  with  the  best 
possible  balance  of  LCC  and  Design  to  Cost  (DTC)  requirements,  schedule,  and 
operational  effectiveness.  In  addition,  continual  risk,  assessment  of  the  elements  of  the 
proposed  system  will  be  made  to  identify  areas  of  uncertainty  that  must  be  overcome 
in  later  program  phases.  Components  whose  performance  is  critical  to  program 
success  may  be  prototyped  to  minimize  risk.  A  System  Design  Review  (SDR)  will  be 
held  at  the  end  of  this  phase  (or  early  in  the  FSD  phase)  to  provide  a  preliminary 
allocation  or  requirements  to  hardware  and  software  CIs,  personnel,  and  facilities. 
This  system  design  will  normally  be  supported  by  a  proposal  for  the  FSD  phase, 
including  program  management  plans.  A  Decision  Coordinating  Paper  (DCP)  and 
Integrated  Program  Summary  (IPS)  are  prepared  by  the  Government  Program  Office 
for  review  by  the  SARC(s)  and  DSARC.  If  all  requirements  are  satisfied,  a  Ratified 
DCP,  IPS  recommending  approval  is  forwarded  to  SECDEF.  A  SECDEF  approval 
authorizes  contract  awards  for  the  next  phase. 
3.    Full  Scale  Development  (FSD)  Phase 

To  initiate  the  FSD  phase,  the  Government  negotiates  a  contract  with  one 
or  more  contractors.  The  purpose  of  the  FSD  phase  is  to  ensure  that  detail  design  is 
complete,  major  problems  have  been  resolved,  achievement  of  performance 
requirements  has  been  demonstrated  by  testing,  and  the  designed  system  is  producible. 
The  type  of  contract  is  dependent  on  perceived  program  risks,  but  usually  a 
development  contract  is  a  cost-plus-incentive  type  to  encourage  innovation  and 
tradeoffs  when  technical  and  engineering  problems  are  uncovered  in  this  phase. 
Continual  risk  assessment  is  characteristic  of  the  FSD  phase.  A  cost-type  contract 
award  will  require  the  contractor  to  operate  a  management  system  that  satisfies 
Government  Cost  Schedule  Control  Systems  Criteria  (C,  SCSC)(Ref.  MIL-STD-S81). 
The  FSD  design  activity  is  based  on  Part  I  specifications  (Type  B,  Ref.  MIL-STD-490) 
and  System  Engineering  documentation,  with  changes  directed  by  the  approved  DCP. 
as  the  basis  for  design. 
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The  Preliminary  Design  Review  (PDR)  is  held  after  preliminary  design 
effort,  but  before  the  start  of  detailed  design.  It  provides  authentication  of  the  Part  I. 
Type  B  (MIL-STD-490)  development  specifications.  The  Critical  Design  Review 
(CDR)  is  conducted  for  each  CI  before  release  of  the  design  for  production.  These 
reviews  may  culminate  in  a  system  CDR  which  reviews  the  completeness  of  preceding 
CDRs  and  ensures  adequacy  of  interfaces. 

The  FSD  phase  provides  verification  of  performance  capability  before 
operational  use  by  testing  the  system  or  equipment  in  its  intended  environment.  The 
results  of  this  testing  and  any  proposed  changes,  refurbishments,  and  corrected 
deficiencies  are  evaluated  in  a  series  of  reviews  and  audits  intended  to  provide 
confidence  that  the  system  has  been  developed  sufficiently  to  proceed  with  production 
for  operational  use. 

The  Functional  Configuration  Audit  (FCA)  is  conducted  on  each  CI  before 
acceptance  of  the  development  effort.  The  CI  must  represent  the  configuration 
released  for  production  and  demonstrate  compliance  with  the  Part  I  development 
specifications  (Type  B.  MIL-STD-490).  The  Physical  Configuration  Audit  (PCA)  may 
be  accomplished  in  the  FSD  phase,  but  is  usually  done  in  the  beginning  of  the 
Production  and  Deployment  phase  on  the  first  deliverable  CI  that  is  built  on  hard 
tooling.  A  Production  Readiness  Review  (PRR)  is  held  at  the  end  of  the  FSD  phase  to 
verify  that  the  system  is  ready  to  proceed  into  the  next  phase. 

The  output  of  FSD  should  result  in  a  tested  design  that  meets  contract 
requirements  and  documentation  necessary  to  enter  the  Production  and  Deployment 
phase,  including  Part  II  detail  specifications  (Type  C,  MIL-STD-490),  a  proposed  RFP 
for  the  Production  and  Deployment  phase,  and  an  update  of  the  plans  proposed  in  the 
Validation  phase.  This  data  package  receives  a  DCP  update,  SARC,  and  DSARC 
review.  When  all  aspects  of  FSD  have  been  accomplished,  the  DCP  is  forwarded  to 
SECDEF  for  approval  of  production. 

4.    Production  and  Deployment  Phase 

The  primary  objective  of  the  Production  and  Deployment  phase  is  to 
produce  and  deliver  an  effective,  supportable  system  at  an  optimum  cost.  In  a 
production  run  where  many  items  are  to  be  delivered,  manufacturing  is  usually 
accomplished  in  two  segments.  The  first  segment  starts  with  low  rate  production  of 
initial  product  batches  or  blocks  and  gradually  increases  to  peak  rate  production  as 
changes    resulting    from    initial    operational    use,    testing,    production    tooling,    and 
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manufacturing  are  incorporated.  Typically  the  first  production  configuration  item  from 
hard  tooling  is  subjected  to  a  PCA.  Once  it  has  been  established  that  a  production 
article  is  built  in  accordance  with  the  Part  II  detail  specifications,  the  PCA  is  complete 
and  an  approved  production  baseline  is  established  for  the  configuration  item  audited. 
Once  the  PCAs  for  all  the  CIs  are  completed,  a  system  level  PCA  is  accomplished  and 
the  product  baseline  for  the  system  is  established. 
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